vision scope template example file - mof

Vision ScopeExchange Delivery Planning Services

Prepared for

Customer_Name

Friday, 11 November 2011

Version 1

Prepared by

EDPS Team

Contributors

EDPS Delivery Partner

333Customer_Name3

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.

© 2008 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express authorization of Microsoft Corp. is strictly prohibited.

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

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Page iiVision Scope, Exchange Delivery Planning Services, Version 1 DraftPrepared by EDPS Team"document.docx" last modified on 11 Nov. 11, Rev 2

333Customer_Name3

Revision and Signoff Sheet

Change Record

Date Author Version Change reference

Reviewers

Name Version reviewed Position Date

Sign-off Form

Name Version approved Position Date

Page iiiVision Scope, Exchange Delivery Planning Services, Version 1 DraftPrepared by EDPS Team"document.docx" last modified on 11 Nov. 11, Rev 2

333Customer_Name3

Table of Contents

1 Introduction................................................................................................................................... 2

2 Problem Statement....................................................................................................................... 3

3 Business Statement and Goals...................................................................................................4

4 Project Vision and Scope............................................................................................................6

4.1 Vision Statement.....................................................................................................................6

4.1.1 Benefits Analysis................................................................................................................6

4.2 Scope of Project...................................................................................................................... 6

4.2.1 Project Phases and Objectives In Scope...........................................................................7

4.2.2 Project Phases and Objectives Out of Scope....................................................................8

4.2.3 Project Milestones and Deliverables..................................................................................8

4.2.4 Assumptions and Dependencies........................................................................................9

4.3 Acceptance Criteria...............................................................................................................10

4.4 Conditions of Satisfaction......................................................................................................10

5 Project Requirements................................................................................................................11

5.1 Solution Requirements..........................................................................................................11

5.1.1 Business Requirements...................................................................................................11

5.1.2 Operational Requirements...............................................................................................12

5.1.3 Technical Requirements..................................................................................................12

5.2 Availability Requirements......................................................................................................13

5.2.1 Availability Definitions......................................................................................................13

5.2.2 Identified Availability Requirements.................................................................................14

5.3 SLA’s and OLA’s................................................................................................................... 14

5.3.1 Determining Service Level Agreements...........................................................................14

5.3.2 Service Level Agreements derived from the Solution Requirements...............................16

5.3.3 Service dependencies......................................................................................................18

5.3.4 Operating Level Agreements...........................................................................................19

5.4 Quality of Service: Multi-Tier Service Levels Model...............................................................20

5.4.1 Service Level Tier Definitions...........................................................................................20

5.4.2 Service Mapping to Service Level Tiers...........................................................................21

6 Solution Design Strategies........................................................................................................22

6.1 Current Environment.............................................................................................................22

6.1.1 Users................................................................................................................................ 22

6.2 Architectural Design Strategy................................................................................................22

6.3 Deployment Design Strategy.................................................................................................24

6.3.1 Migration and Transition Scenarios..................................................................................24

6.4 Project Constraints................................................................................................................24

6.4.1 Budget constraints...........................................................................................................25

Page ivVision Scope, Exchange Delivery Planning Services, Version 1 DraftPrepared by EDPS Team"document.docx" last modified on 11 Nov. 11, Rev 2

333Customer_Name3

6.4.2 Timing constraints............................................................................................................25

6.4.3 Resource constraints.......................................................................................................25

7 Risk Evaluation and Analysis....................................................................................................26

7.1 Risk ratings............................................................................................................................ 26

7.2 Risk factors............................................................................................................................ 27

8 Appendix A: Project Structure..................................................................................................28

8.1 Team Roles and Responsibilities..........................................................................................28

8.2 Project Management Strategy...............................................................................................29

8.3 Phased Delivery of the Solution............................................................................................30

9 Appendix B: Approved Statement of Work..............................................................................32

Page vVision Scope, Exchange Delivery Planning Services, Version 1 DraftPrepared by EDPS Team"document.docx" last modified on 11 Nov. 11, Rev 2

333Customer_Name3

Template Guidance

Description: The Vision/Scope document represents the ideas and decisions developed during the Envisioning phase. The goal of the phase, represented by the content of the documentation, is to achieve team and customer agreement on the desired solution and overall project direction.

This Vision/Scope template is based on a general MSDM template tailored for specifics of engagement focused on Exchange 2010.

The Vision/Scope document is organized into four main sections:

Problem and Business Statements: A description of the project motivation, customer’s current situation and needs

Vision and Scope: The boundary of the solution defined though the range of features and functions; what is in and out of scope, a phased delivery strategy and the criteria by which the solution will be accepted by customer

Solution Design Strategies: The architectural and technical design strategies and approaches that will be used to create the customer’s solution

Project Structure: How the project will be organized, managed, and delivered.

Throughout the template, look for shaded text. Where shaded text appears, click the field and follow instructions.

Depending on the complexity of the project, not all of the sections might be filled out, or some sections might be cut back significantly.

Justification: Vision/Scope documentation is usually written at the strategic level of detail and is used during the Planning phase as the context for developing more detailed technical specifications and project management plans. It provides clear direction for the project team; outlines explicit, up-front discussion of project goals, priorities and constraints; and sets customer expectations.

Team Role Primary: Product Management is the key driver of the Envisioning phase and is responsible for facilitating the team to the Vision/Scope approved milestone. Product Management defines the customer needs and business opportunity or problem addressed by the solution.

Team Role Secondary: Program Management is responsible for articulating the Solution Concept, Goals, Objectives, Assumptions, Constraints, Scope and Solution Design Strategies sections of this document.

Page 1Vision Scope, Exchange Delivery Planning Services, Version 1 DraftPrepared by EDPS Team"document.docx" last modified on 11 Nov. 11, Rev 2

333Customer_Name3

1 INTRODUCTION

The Vision/Scope document represents the ideas and decisions developed during the envisioning phase. The goal of the phase, represented by the content of the documentation, is to achieve team and customer agreement on the desired solution and overall project direction. A Vision/Scope document is intended to:

Define a clear direction for the project team Set expectations Outlines explicit project goals, priorities, and constraints Provide the criteria for the design and deployment of the solution

A Vision Scope document should address the what, where, when, why, who, and how of the project. It is usually written at a strategic level of detail and the project team uses it during planning as the context for developing technical specifications and project management plans in greater detail.

Project vision and project scope are distinct concepts, and successful projects require both. Project vision is an unlimited view of the solution. Project scope identifies the parts of the vision that a project team can accomplish within its constraints. The vision/scope document defines both concepts.


333Customer_Name3

2 PROBLEM STATEMENT

Guidelines for a Problem Statement

Purpose: Establish the motivation for the project

Responsibility: Product Management

Length: Less than one page, ideally 2-3 paragraphs

Guidelines: Stay at a high level, use business language

This section is a message to the senior executives and project sponsors reading this document. Most probably this will be the only section they read, so make sure it contains a concise description of the problem and delivers the proper executive message regarding project motivation, scope, and methods Microsoft is going to use to achieved the project goals.

… <Insert problem description here>

… <Describe project motivation and goals>

To address these goals, Microsoft / Partner will assist Customer_Name to design and deploy the Microsoft Exchange 2010 messaging solution. Microsoft / Partner will work with to perform envisioning, planning, designing the end state architecture, building and configuring test lab and testing the solution, helping with initial server deployment and migration of the pilot group of users. In the end state Customer_Name will have the fully functional Exchange 2010 infrastructure ready to accept the full scale migration.

To scope the project properly and to accomplish its goals in the best possible way, Microsoft will leverage the Microsoft Solutions Framework (MSF) approach as a proven framework foundation for the solution design and deployment projects.


333Customer_Name3

3 BUSINESS STATEMENT AND GOALS

In this section, write a statement of the customer’s situation. It should be expressed in business language, rather than technical terms. The Business Statement is written concisely using a business executive’s voice. This section should demonstrate that you understand the customer’s current environment and its desired future state. This information is the overall context for the project.

When describing the customer’s current situation that creates the need for the project, you may include a statement of the customer’s opportunity and the impact of capitalizing on that opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining and leveraging knowledge). You may also include a statement of the customer’s problem and the impact of solving the problem (revenue protection, cost reduction, regulatory compliance, alignment of strategy and technology). You should include a statement that connects the customer’s opportunity/problem to the relevant business strategy and drivers.

This section will start with a description of the customer’s current messaging, communications, and collaboration environment, followed by an explanation of the business problem or reasons for migrating to Exchange 2010. This section should answer the following questions:

Who is the customer, what is their line of business?

How large (number of seats & locations) is this customer?

What is the strategic goal of the project?

What are the main business reasons to implement Exchange 2010?

What is the nature of their current messaging system? What do they use messaging for? What functionality is needed from the messaging solution?

What are the key benefits of Exchange 2010 that are driving this project? You should show how these benefits match the business requirements:

Consolidation

Unified Messaging

Increased Productivity

High Availability / Site Redundancy

Compliance / Archiving

Etc.

Stay at the high level business description and do not go into technical details as this more detailed information is considered a part of the assessment and discovery phase and should be included in the EDPS - Deployment Planning Recommendations Template (in case of 15 days engagement) document.

Justification: The Business Statement demonstrates that you understand the customer’s situation from the business point of view and provides the project team and other readers with the strategic context for the remaining sections.


333Customer_Name3


333Customer_Name3

4 PROJECT VISION AND SCOPE

4.1 Vision Statement

This section will contain the Vision statement for the customers Exchange 2010 project.

Guidelines for a Vision Statement

Purpose: Establish the long-term vision and provide design-making content. Provide unbounded sustaining motivation.

Responsibility: Product Management

Length: No more than a couple of paragraphs (it should be possible to summarize in one sentence fitting onto one PowerPoint slide.

Guidelines: Balance all the interests to arrive at a single Vision Statement; surface enterprise architecture implications early.

Clearly and concisely describe the future desired state of the customer’s environment once the project is complete. This can be a restatement of the project goals; however, it is written as if the future state has already been achieved. This statement provides a context for decision-making. It should be motivational to the project team and the customer.

Justification: A shared Vision Statement among all team members helps ensure that the solution meets the intended goals. A solid vision builds trust and cohesion among team members, clarifies perspective, improves focus and facilitates decision-making.

4.1.1 Benefits Analysis

Describe how the customer will derive value from the proposed solution. Connect the business goals and objectives to the specific performance expectations realized from the project. These performance expectations should be expressed numerically. This section could be presented using the following subsections:

1. Business Goals and Objectives

2. Business Metrics

3. Business Assumptions and Constraints

4. Benefits Statement

Justification: Benefits Analysis demonstrates that you sufficiently understand the customer’s situation. It also defines the customer’s business needs, which may provide vital information for making solution/technology recommendations.

4.2 Scope of Project

The following sections describe the scope of the project for this customer.

Guidelines for a Scope Statement

Purpose: Map reality against the vision and establish what the customer deems to be essential for success. Less essential features would be shifted into future releases. Remember, information for this section and for the overall document is for the ENTIRE project not just the envisioning phase.

Responsibility: Program Management


333Customer_Name3

Length: As succinct as possible (one to two pages).

Guidelines: Be SMART (Specific, Measurable, Achievable, Results-based, Time-oriented). Clearly state what is out of scope.

Place a boundary around the solution by detailing the range of features and functions, by defining what is out of scope, and by discussing the criteria by which the solution will be accepted by users and operations. The scope clearly delineates what stakeholders expect the solution to do, thus making it a basis for defining project scope and for performing many types of project and operations planning.

The preceding Vision Statement provides a motivating goal for the team working on this project. As such, we write it with broad brush strokes in order to provide a shared and inspiring ideal. The statement provides context for decision-making at later stages of this project when deciding among features, cost and project timeline. It is not provided to be a legally binding contract for the solution. The revisions of this document going into the future provide the detail scope of what will and will not be accomplished to meet the vision. To facilitate project management and delivery of the solution, the project is broken into phases according to the general Microsoft Solutions Framework (MSF) project management strategy. For each phase, we determine the specific goals and objectives that are considered within or out of scope of the project and provide features and functionality of the solution.

4.2.1 Project Phases and Objectives In Scope

At different phases of the project, there are multiple tools and technologies available to facilitate execution of the tasks specific for this stage. For example, for the server sizing (part of the Planning phase) make sure that you leverage Exchange Storage Calculator. For the Testing phase (assuming the performance testing is determined in scope of the project) the following tools should be used: Load Generator, JetStress and ExMon. Testing results and output received from these tools should be included in the corresponding document deliverables.

Within the scope of this project, Partner works with Customer_Name over a period of time on a schedule to be mutually agreed. The engagement is based on the following phases (determined in accordance with the Microsoft Solutions Framework (MSF) strategy – refer to section 8.3 “Phased Delivery of the Solution” for details):

Envisioning (Discovery and Assessment) phase – Information discovery, data collection, assessment of the current environment and determination of the project requirements and SLA’s;

Planning (design) phase – Architecture design, lab testing and migration planning and determining the supported and recommended design and upgrade options;

Developing and testing phase – Building and configuring the Proof of Concept (POC) test lab and performing functional performance testing of the deployment and migration processes to validate the proposed approach; performance testing should be also conducted at this stage if lab infrastructure and project plan permit;

Stabilizing (pilot deployment) phase – Preparing the target infrastructure for the pilot, pre-configuring servers, Active Directory, and network, and performing the actual pilot deployment; this stage also includes the primary post-deployment configuration tasks to ensure proper functionality during the transition co-existence stage; performing the transition/migration for a pilot group of users (typically part of the IT personnel plus identified representatives of the various business departments);

The following objectives for each phase are identified to be in scope of the project:

Objective Rational


333Customer_Name3

Objective 1 description


Table 1: Business Objectives In Scope

4.2.2 Project Phases and Objectives Out of Scope

The following project phases are considered out of the scope of this project, but could be added to the scope (affecting the engagement timeline and cost) with a customer approved change order if required:

Deployment phase – Deploying additional servers; performing the full scale transition/migration for the computers, users, mailboxes, and applications as described in the migration plan; this phase can be staged depending on customer requirements, and extend over several weeks or even months to minimize disruption to the users and ensure proper change management conformance and business continuity.This phase is the last phase defined in the Microsoft Solutions Framework model.

Operation phase – Performing post-migration tasks, monitoring the new environment, researching and resolving operational issues; at the end of this stage, Microsoft highly recommends performing the Active Directory and Exchange health check leveraging Microsoft Premier rapid assessment program (RAP) offerings; this phase also includes uninstalling and decommissioning the (now obsolete) old servers depending on the selected transition scenario, and cleaning up the environment.This phase belongs to Microsoft Operations Framework (MOF) model and refers more to the operations process than to engineering and implementation.

The following project objectives are considered out of the scope of this engagement, but could be later added to the scope with a customer approved change order if required:

Objective Rational

Objective 1 description Explanation of why it is considered out of scope and when/how it can be brought to the project


Table 2: Business Objectives Out of Scope

4.2.3 Project Milestones and Deliverables

During the course of this project, the following milestones are considered as phased project deliverables and will be achieved as part of the engagement:

# Project Milestones Timeline estimate Rational

1. End state architecture design approved

2. Migration plan approved

3. Test lab built and configured

4. Proof of Concept testing completed

5. Active Directory and network prepared for Exchange 2010 deployment

6. Exchange 2010 servers deployed

7.

Table 3: Planned project milestones


333Customer_Name3

These milestones are defined in accordance with the MSF project phasing model.

It should be noted that the timeline estimates for the planned project milestones as defined above should be considered initial estimates at this stage and can be adjusted basing on project dependencies and assumptions and on the actual project workflow. The project plan will be responsible for keeping track of the project timeline and the milestone schedule.

The following document deliverables will be provided as a result of this engagement:

# Document Deliverable Format Rational

1. Project Plan Microsoft Project 2007

2. Vision and Scope document Microsoft Word 2007or Adobe PDF

3. Functional Specification (Architecture Design document)

Microsoft Word 2007or Adobe PDF

4. Proof of Concept Lab design Microsoft Word 2007Microsoft Visio 2007

5.

Table 4: Planned document deliverables for the project

4.2.4 Assumptions and Dependencies

In this subsection, list the project assumptions and dependencies.

Project assumptions are the statements that could not be verified at the current time but are essential for the overall success of the project. Examples could be the presence of necessary hardware for server deployment or ownership of the necessary server licenses. Other assumptions may refer to the projected changes in the customer environment, such as addition or decommission of the physical locations / datacenters, changes in the network infrastructure / connectivity, implementation of business applications adding requirements to the project, or planned organizational changes.

Example: “Basing on the information from the CIO, it is assumed that the company upgrades its inter-site WAN links to 100 Mbps bandwidth with guaranteed 50ms latency within 3 months from the project start date. These link characteristics are required for the selected high availability design for Exchange 2010.”

Project dependencies are the factors that affect the normal flow and may impact the overall success of the project, but are not part of the current project itself. Examples could be network or storage infrastructure deployment or identification of the SOX regulatory compliance requirements based on the ongoing company audit.

Example: “Design decision regarding messaging records management and e-mail archiving architecture depends on the final regulatory compliance requirements that are currently being determined by the customer”.

Proper identification of the project assumptions and dependencies is required to initiate and establish necessary communications with the other project teams at the early stage and is extremely important to ensure that this information is communicated to the project stakeholders and proper expectations are set.


333Customer_Name3

4.3 Acceptance Criteria

Define the metrics that must be met in order for the customer to understand that the solution meets its requirements.

Justification: Acceptance Criteria subsection communicates to the project team the terms and conditions under which the customer will accept the solution.

4.4 Conditions of Satisfaction

Define the conditions and circumstances by which the customer’s operations team judges the solution ready to deploy into the production environment. Once deployed, the customer takes ownership of the solution. This section may specify the customer’s requirements for installing the solution, training operators, diagnosing and managing incidents, and so on.

Justification: Operational Criteria communicate to the project team the terms and conditions under which the customer will allow deployment and ultimately sign off on the project. This information provides a framework for planning the solution’s deployment.

There should be a separate dedicated Conditions of Satisfaction (COS) document prepared by the Engagement Manager for this engagement. It can be a good idea to quote this document in this section. Work with the Engagement Manager to accomplish this.


333Customer_Name3

5 PROJECT REQUIREMENTS

5.1 Solution Requirements

Identify what the solution must do. These requirements can be expressed in terms of functionality (for example, implementing Unified Messaging (UM is only as a example here!) will allow the users to receive their voicemails in their Inbox, access their mailboxes from any phone, and so on) as well as the rules or parameters that apply to that functionality (for example, the voicemails should be retained for 6 months according to compliance regulations, or the messaging service should be restored within the 2 hours in case of a mailbox server crash). Requirements exist at the following identified levels:

Business requirements

Operational requirements (supportability and usability)

Technical requirements

Availability requirements (including service and operating level agreements)

Justification: Solution requirements are the key input to developing product scope and design strategies. Requirements are the bridge between the product functionality and solution architecture. A complete Statement of Requirements demonstrates that Microsoft understands its customer’s needs. This statement also becomes the baseline for more detailed technical documentation in the Planning phase. This is perhaps the most important section in this document. Good requirements analysis lowers the risk of downstream surprises.

Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.

5.1.1 Business Requirements

Business requirements are the most important drivers for the project and for the solution architecture in general. Business requirements are general by nature; they justify the technology to be used and determine the scope of products and solutions that may be utilized to achieve the end state architecture. They may significantly impact the features/functionality and overall project scope and timeline.

Basing on the communications with the project executive sponsors and stakeholders and customer IT personnel, we identified the following business requirements for the project:


Requirement Rational

Integration of messaging and telephony communications into a unified system with a single application providing interface to the end users

Full compliance with regulatory requirements of SOX and HIPAA

ROI value compensating the cost of ownership within 3 years from initial deployment

Ability to host 25,000 mailboxes with 15,000 of them being UM enabled, and to accommodate projected annual growth of 10% for both e-mail and UM users for 5 years


333Customer_Name3

Table 5: Business requirements

5.1.2 Operational Requirements

Operational requirements describe the supportability and usability of the solution. They are formulated from the two distinct standpoints: the standpoint of the IT personnel who will administer / manage / support the end state design, and the standpoint of end users who will utilize the features and functionality of the solution.

Basing on the communications with the project stakeholders and customer IT personnel, we identified the following operational requirements for the project:



Centralized management and administration of all messaging servers throughout the enterprise

Internal message delivery time of <15 sec globally throughout the enterprise

Continuing support for public folders leveraging existing organizational forms library

Ability to search and archive voicemails in user mailboxes and use separate retention policy

Table 6: Operational requirements

5.1.3 Technical Requirements

Technical requirements specify the technical parameters and feature characteristics of the solution. They are formulated from the standpoint of the IT personnel and are secondary to and dependent on the business requirements. Technical requirements are to ensure that the delivered solution will be able to meet the business requirements and provide necessary scalability and reliability.

Basing on the communications with the project stakeholders and customer IT personnel, we identified the following technical requirements for the project:



Support for mailbox quotas of 500MB with 30 days deleted items retention

Seamless integration of the existing Cisco Call Manager 5.0 telephony system

Ability to create custom Auto-Attendants for different company departments

Support for two-factor authentication for all types of external mail clients

Table 7: Technical requirements


333Customer_Name3

5.2 Availability Requirements

5.2.1 Availability Definitions

Availability requirements are typically the most cumbersome and hard to determine properly. There should be a proper distinction between service availability and server /data availability requirements.

Service availability determines the level of availability of specific product functionality to the end user. It measures percentage of time when clients are actually able to use the service for the full end-to-end functionality. For example, messaging service (ability to send and receive e-mails) should be available for 99.9% of the time. This is the top and most critical availability requirement.

Server availability determines the level of availability of specific server(s). It measures percentage of time when server is running and offering services to the clients. Server availability is necessary but not sufficient condition for the service availability, because service availability depends on many additional factors, for example on availability of network connections. Therefore, server availability is always higher than the service availability.

Data availability determines the level of availability of the actual data used by servers and needed to properly service the clients. It measures percentage of time when a proper data is available to the servers. This is different from server availability. Even if the servers are healthy and function properly, corrupted or unavailable data will create service downtime. Data availability combines with server availability to become a major contributing factor for the service availability.

Service availability is always lower than server or data or even combined availability. For example, both server and storage might be up and running but network connection might be down, or client workstation might be broken, or client application might be crashing.

Typically, service availability is a critical business requirement while server or data availability is not (end users don’t care if the server or disk storage device is up or down, they do care if they can send and receive messages and access their mailboxes). Therefore, the term “high availability” usually refers to the service availability. However, proper determination of service availability introduces many additional concepts and factors.

Every service should provide certain level of availability required by the corresponding service tier SLA. For example, 99.9% (“three nines” or 8.76 hours downtime a year) is required for both planned and unplanned downtime but 99.99% (“four nines” or 53 minutes downtime a year) is desirable and required for unplanned downtime only. These service availability requirements can be presented in the following table:


Service Availability level Unplanned downtime only Both planned and unplanned downtime

99.9% Unacceptable Required

99.99% Required Desired / optional

Table 8: Service Availability levels

The “downtime” term here refers to the loss of service to the end users.

For the reference, the typical widely used service availability levels are described below:

99.999% (“five nines”) – means 5.256 minutes of downtime per year; 99.99% (“four nines”) – means 52.56 minutes of downtime per year; 99.9% (“three nines”) – means 8.76 hours of downtime per year; 99% (“two nines”) – means 87.6 hours, or 3.65 days, of downtime per year;


333Customer_Name3

90% (“one nine”) – means 36.5 days of downtime per year.

As mentioned above, “high availability” term typically refers to the service availability. However, one should realize that this introduces the chain of dependencies between the services. Namely, dependable services cannot have higher availability than the services they depend on. For example, if availability level of network services is 99.5%, then availability of messaging services just cannot be higher than that, so 99.99% SLA is not realistic in this case.

The following formula can be used to calculate the actual messaging server availability for the specified time period in order to validate if the requirements are met:

Availability=(1− UDTTMA−PDT )∗100%

Here UDT = Unplanned downtime, PDT = Planned downtime, TMA = Total minutes of service availability in the period times number of mailbox and public folder servers.

Dedicated Microsoft tools can be also leveraged to monitor and control server and service availability, such as Desired Configuration Monitoring (DCM) scorecards integrated with Microsoft Operations Manager or Microsoft Performance Point server.

5.2.2 Identified Availability Requirements

Basing on the communications with the project executive sponsors and stakeholders and customer IT personnel, we identified the following general availability requirements for the project:



Messaging service should be available to the end users for 99.9% of time (excluding planned downtime)

Voicemail service and OVA should be available to the end users for 99.5% of time (excluding planned downtime)

Table 9: General availability requirements

5.3 SLA’s and OLA’s

5.3.1 Determining Service Level Agreements

Service Level Agreements (SLA’s) are the functional requirements for the service recovery (in the situations when service availability is broken) that the IT has to meet. Generally, these agreements determine the speed and quality of service recovery operations in case of service failure.

The major SLA requirements for the service recovery operations are Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For the messaging service, these terms translate into the following:

Recovery Point Objective (RPO) represents the minimum tolerated time interval for the duration of which messages could be lost.


333Customer_Name3

Recovery Time Objective (RTO) represents the time required to bring the service back online after a failure.

These concepts are illustrated on the following figure showing messaging service recovery objectives:

Time

Last good backup

System crash

Dial-tone service restored

Full service restored

T0 T1 T2 T3

Lost mail No service

Service Level Agreements

Recovery Point Objective: RPO = T1 – T0

Recovery Time Objective: RTO = T2 – T1 or T3 – T1

Figure 1: RPO and RTO definitions for messaging service

The values of RPO and RTO should be defined separately for separate SLA’s. The typical SLA table for RPO and RTO might looks like follows (this is just a typical example, actual business and technical requirements should dictate specific values in each situation described):


SLA objective Single mailbox recovery

Single database recovery

Single server recovery (storage remained intact)

Data recovery (servers and storage devices with backup remain intact)

Storage recovery (storage devices and all data are lost)

Site recovery (catastrophic disaster, all servers and storage lost at the site)

RPO

(how much data can be lost)

0 (every message can be recovered)

2 hours 0 (messages accumulate in the queues)

2 hours 2 – 24 hours depending on data replication and backup schedule

8 - 24 hours depending on data replication and/or backup technologies used

RTO for service

(how fast should service be restored)

30-60 min (non-critical failure since service for other users is not interrupted)

2 hours 1-2 hours 15-30 min (time needed to provide storage for dial-tone database)

2-8 hours (time needed to provide new storage and present it to servers)

Strongly determined by technology used, e.g. 10-15 min for the cluster or 2-4 hours for a stand-alone server

RTO for data

(how fast should access to historical data be restored)

4-6 hours (non-critical failure since service for other users is not interrupted)

2-4 hours 1-2 hours Strongly determined by technology used, e.g. 15 min for VSS snap clone restores and 8+ hours for restore from streaming backup

Full data recovery depends on data replication and/or backup/restore technologies and may take up to several days

Full data recovery depends on data replication and/or backup/restore technologies and may take up to several days

Table 10: Sample RPO and RTO SLA's for different scenarios

The main idea is that technological solutions chosen for DR (disaster recovery, being a result of the catastrophic site crash) and OR (operational recovery, everything that is scoped below the site recovery) procedures are tightly connected with RTO SLA’s and mutually affect each other.

In order to facilitate the decision on storage replication and data recovery design, it might be useful to compare potential SLA values for different replication scenarios, such as follows:


333Customer_Name3


Failure Mode SCC + VSS Clones

SCC + Sync Replication

CCR (1 site)

Geographically Dispersed CCR

CCR (in-site) + SCR (out-site)

RTO Server Node < 5 min N/A – use SCC < 5 min < 5 min N/A – use CCR

LUN / Physical Corruption

< 1 hour 15 min – 1 hour < 5 min < 5 min N/A – use CCR

Single Array / Full Storage

Days < 15 min < 5 min < 5 min N/A – use CCR

Site Days < 15 min Days Hour < 1 hour

RPO Server Node 0 0 1 Log 1 Log 1 Log

DB LUN 0 0 0 0 N/A – use CCR

Log LUN Point in Time 0 / Point in Time 1 Log 1 Log 1 Log

Single Array / Full Storage

24+ hours 0 1 Log 1 Log 1 Log

Site 24+ hours 0 24+ hours 1 Log 1 Log

Table 11: Points of Failure and the Effect on RPO/RTO

5.3.2 Service Level Agreements derived from the Solution Requirements

Service Level Agreements (SLA’s) are the functional requirements for the service recovery (in the situations when service availability is broken) that the IT has to meet. Generally, these agreements determine the speed and quality of service recovery operations in case of service failure.

The SLA requirements do not appear from the thin air; they reflect on the technical level the actual business and operational requirements. Properly derived SLA’s originate from the identified and quantified business and operational requirements as listed above.

The general SLA’s typically come from business requirements. They can and should be defined for different components of the messaging services:


SLA objective Internal messaging(e-mail within the org)

External messaging(e-mail out of the org)

External client access(from public network)

Outlook Voice Access Voice mail

RPO(how much data can be lost)

5 min 2 min N/A N/A(same as e-mail)

30 min

RTO for service(how fast should service be restored)

30 min 60 min 60 min 2 hours 2 hours

RTO for data(how fast should access to historical data be restored)

4 hours N/A N/A N/A(data not affected)

4 hours

Table 12: General Service Level Agreements for the messaging services


333Customer_Name3

The more detailed SLA’s should be determined for each server role separately, because different Exchange server roles provide different service functionality. These role specific SLA requirements have been identified as follows:


Server role Requirement SLA value

Mailbox Server RTO for mailbox server recoveryRTO for mailbox data recovery

15 min/server2 hours/database

Client Access Server RTO for service for internal clientsRTO for service for external clients

2 hours4 hours

Hub Transport Server Recovery of internal mail flow 2 hours

Edge Transport Server Recovery of external mail flow 4 hours

Unified Messaging Server OVA, voicemail and fax flow recovery 4 hours

Table 13: SLA requirements by server role

However, the general SLA’s, even divided by server role, do not take into account different possible levels of recovery, starting with simple recovery for a single mailbox or even message, and ending with a Disaster Recovery (DR) when the entire site (datacenter, physical location) needs to be recovered. Therefore, they should be further elaborated, and, according to the sample shown above, different SLA’s should be defined for different levels of recovery.

The following table lists the identified Service Level Agreements for different recovery levels which the end to end messaging system must meet for the customer.

SLA objective Single mailbox recovery

Single database recovery

Single server recovery (storage remained intact)

Data recovery (servers and storage devices with backup remain intact)

Storage recovery (storage devices and all data are lost)

Site recovery (catastrophic disaster, all servers and storage lost at the site)

RPO

(how much data can be lost)RTO for service

(how fast should service be restored)RTO for data

(how fast should access to historical data be restored)

Table 14: Service Level Agreements

Similar breakdown should be performed for each specific server role as specified above in Table 13.

Present here separate tables for different roles if you have specific SLA requirements for different recovery levels for these roles.


333Customer_Name3

5.3.3 Service dependencies

As mentioned above, service availability is a complex term depending on the chain of service dependencies. Typical service dependencies hierarchy for the major IT services is illustrated below:

Networking services

(Site connectivity, availability, bandwidth / latency, redundancy, DNS, WINS, DHCP,

RAS/VPN)

Directory services

(User directory, services directory, resource management, security, access control, address lists, application data)

Unified Communications

(E-mail, voicemail, mobility, instant messaging, presence, conferencing,

telephony and fax integration, external publishing)

Asset Management

(Server and client management, operations management, OS and software

deployment, profile and policy management, desktop protection/security,

patches and updates, monitoring, reporting)

Information Management

(Document management, portal collaboration, archiving, life cycle

management, CRM systems, database systems, business applications, regulatory

compliance, rights management)

Figure 2: Typical IT Service Dependencies

These service dependencies affect service availability for specific services and contribute to determining service level agreements (SLA’s) as well as interdepartmental operating level agreements (OLA’s).

Therefore it is important to distinguish between service level agreements (SLA’s) which constitute the agreements between service provider and the client, and operating service agreements (OLA’s) that constitute the agreements between different providers. SLA strongly depends on OLA’s and cannot exceed their cumulative value. For example, if the OLA for the hardware department to provide and mount the new server hardware is 2 hours, and OLA for the server department to install and configure the operating system is 2 hours, it doesn’t make sense to set the server recovery SLA for the requesting department to less than 4 hours. Of course, there might be additional OLA’s associated with additional links in the OLA dependencies chain.

The following figure illustrates how the resulting SLA depends on the chain of OLA’s hat affect the overall service recovery time:


333Customer_Name3

Systems Operations

Users

SLA & OLA dependencies: Messaging service recovery

Hardware Operations

NetworkingOperations

Messaging

Windows Server

SLA approved OLA approved

Provisioning hardware

Serverbuild

Joiningnetwork

Joiningdomain

Restoringservice

Recoveringserver

Messaging

Figure 3: SLA and OLA dependencies

This means that the services dependency scheme presented above should be taken into account as well as the interdepartmental OLA dependencies scheme when determining the resulting SLA’s for the particular service.

5.3.4 Operating Level Agreements

Besides the general Service Level Agreements, there might be various Operating Level Agreements (OLA’s) defined for specific operational tasks. The two distinct types of OLA’s are:

Internal OLA’s defined as sub-components of the general messaging service SLA. Within the messaging service scope of agreements, the internal OLA’s can be, for example, backup and recovery times for mailbox databases or individual mailboxes, or server provisioning time for dial-tone disaster recovery. Internal OLA’s contribute to the general SLA for the affected messaging role.

Interdepartmental OLA’s (based on service dependencies) determining service availability for all environmental dependencies that affect messaging service and therefore also contribute to the messaging SLA’s. They represent agreements between different groups within corporate IT such as Windows Operations, Network Operations, Telephony/Communications, Security, Server Engineering, etc.).

The following table lists the identified internal Operating Level Agreements which apply to the customer’s messaging environment for different levels of mail data recovery:


Operating Area Operating Level

Server Database Mailbox Message

Server provisioning N/A N/A N/A

Restore Time

Backup Time

Online Maintenance time


333Customer_Name3

Offline Maintenance time

Cluster failover time N/A N/A

Restore of CAS IIS directories

Route convergence

Table 15: Internal OLA’s within the scope of SLA’s for the messaging service

The following table lists the identified internal Operating Level Agreements which apply to the customer’s environmental dependency services:

Environmental Dependency Requirement OLA value

Active Directory

Identity Management

Storage

Hardware Vendor

Internal Network

External Network

DNS

Data Center power

Vendor service for failed components(i.e. replacing failed equipment)

Telephony Infrastructure

Unified Communications (OCS)

Table 16: Interdepartmental Operating Level Agreements for Exchange Environmental Dependencies

5.4 Quality of Service: Multi-Tier Service Levels Model

5.4.1 Service Level Tier Definitions

In the real life situation not all services are equally important, and service failures create different impact on business. It is recommended to use the multi-tier service level definitions similar to the sample model presented in the following table:

Tier level Tier definition Service availability

Server availability

RTO: Server level

RTO:Datacenter level

RTO:Site level

Mission Critical Failure severely affects the entire company and puts the whole company business at risk

99.5% 99.95% 30 min 4 hours 2 days

Business Critical Failure severely impacts the single department / business unit and puts the affected business at risk

99% 99.9% 2 hours 1 day 3 days

Corporate standard Failure impacts the service functionality but is not critical to the company business

95% 99% 4 hours 3 days 7 days

Business standard Failure impacts the single business but is not critical to the main

90% 95% 1 day 7 days 1 month


333Customer_Name3

functionality

Table 17: Service Level Tiers Model

Present here service level tier definitions as used in the customer environment. Highlight messaging services and any components that are Exchange related or represent environmental dependencies that would affect SLA’s. Raise concerns if you see inconsistencies that might impact the project.

5.4.2 Service Mapping to Service Level Tiers

Each service area and set of functional features defined above consists of different services and functionalities that are not equally important in terms of SLA definitions. This means that the entire service area cannot be solely classified as mission critical or business critical, but typically falls under several categories depending on the service components. This leads to the following sample mapping of service components to the service level tiers described above:

Tier level Network services Directory services Unified Communications Collaboration portals

Mission Critical General and HQ connectivityDNS services

Global CatalogRoot Domain DC’s

E-mail functionality Corporate portal

Business Critical Site connectivity Site level DC’s Fax functionality Business unit portalsCorporate standard DHCP services

WINS servicesChild domain DC’sMonitoring servers

MobilityVoice mailLive Meeting

Site libraries

Business standard Network segment connectivity Instant Messaging Workgroup libraries

Table 18: Service Offerings Tiers: example

This table is presented as an example and should be edited and extended to reflect actual business and availability requirements.


333Customer_Name3

6 SOLUTION DESIGN STRATEGIES

6.1 Current Environment

This section provides a short overview description of the current environment at the customer including the following areas:

Exchange versions Active Directory versions, domains, site topology, site links Exchange 5.5/200x topology, number of mailboxes, sites 3rd-party gateways/connectors, applications etc User population and Mailbox sizes Any directory synchronization tools Administration and administration tools

.

6.1.1 Users

This section provides a short overview description of the current environment from the users perspective including the following areas:

Outlook versions Delegated Access Updating of distribution lists SMTP addresses Usage of public folders User population and Mailbox sizes 3rd-party applications

Ensure that you spend enough time on understanding the user environment, such that a good selection of Exchange 2010 users can be made.

6.2 Architectural Design Strategy

Describe how the features and functions will operate together to form the solution. It identifies the specific components of the solution and their relationships. A diagram illustrating these components and relationships is an excellent communication device.

Justification: The Architectural Design Strategy converts the list of features and functions into the description of a fully functional, integrated environment. This information enables the customer to visualize the solution in its environment. It may drive the selection of specific technologies. The Architectural Design Strategy is key input to the design specification.

The reference text below is intended to facilitate consultant’s effort to describe architectural design for the proposed strategic solution (Exchange 2010). You can/should adjust the section contents below and add necessary customer specific information.

Architectural design strategy for the project is based on the problem and business statements presented above. The strategic goal is Example, pls. replace -> to leverage current messaging infrastructure and protect investment by transitioning to Exchange 2010. Deploying Exchange 2010 will address the company needs and meet business, technical, and availability requirements identified above.


333Customer_Name3

Exchange Server 2010 provides different server roles to separate server functionality and to ensure best scalability and flexibility for different design requirements. Through the introduction of new server roles, Microsoft Exchange Server 2010 setup and deployment has been re-engineered to improve the administrative experience. Exchange 2010 provides five distinct server roles that align with the way messaging systems are typically deployed and distributed. A server role is a unit that logically groups the features and components that are required to perform a specific function in the messaging environment. Each server role includes features that support its function together with related configuration and security settings and a list of predefined tasks for managing and configuring those features.

The five Exchange 2010 server roles are as follows:

Hub Transport Server

The Hub Transport server role handles SMTP mail routing by using Microsoft Active Directory sites and site topology. The Hub Transport server also applies transport rules and policies to incoming and outgoing mail.

Client Access Server (CAS)

The Client Access server role enables mailbox access through Outlook Web Access (OWA), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), Outlook Anywhere (formerly known as RPC over HTTP), and Exchange Server ActiveSync.

Edge Transport Server (not shown on the diagram above)

The Edge Transport server role presents a secure SMTP relay server and provides antivirus and anti-spam protection in a perimeter network for the Exchange organization.

Mailbox Server

The Mailbox server role is responsible for hosting mailbox and public folder databases. A mailbox database contains the users' mailboxes. Mailbox servers support several clustered designs to provide high availability and improve RPO and RTO times for service and data recovery. The Mailbox server also provides messaging records management and applies quotas and limits to the mailboxes and databases.

Unified Messaging Server

Unified Messaging (UM) combines voice messaging, inbound fax, and e-mail messaging into a single messaging infrastructure that can be accessed from a telephone and a computer. UM server integrates with the existing telephony infrastructure, as well as with the Office Communications Server (OCS) 2007 which provides instant messaging, presence, conferencing, and other collaboration features.To support outbound fax, Microsoft offers a bundle solution in partnership with Captaris, manufacturer of the RightFax enterprise fax solution.

In order to meet the business and technical requirements identified above and provide the flexible, scalable, and robust architecture, Microsoft recommends deploying each Exchange Server 2010 role at each datacenter site. For the smaller deployments (smaller datacenters) some roles (except Edge) can be combined to ensure more effective use of hardware and minimize the expenses. However, this is typically not recommended because combining roles introduces performance and scalability implications. Note also that in the scenarios where Mailbox server is deployed in a clustered configuration, Hub Transport cannot be put on a cluster.

The final decision on positioning the server roles and implementing Database Availability Group (DAG), as well as detailed design and sizing for each server role, will be presented in the architecture design document based on the availability requirements identified above.

Additional details go in here.


http://www.captaris.com/microsoft/exchange_bundle/

333Customer_Name3

6.3 Deployment Design Strategy

Document the application of specific deployment scenarios to the Architectural Design. Provide a high level description of the migration plan to be used in transitioning to the end state.

Justification: The Deployment Strategy identifies the specific scenarios that will be applied to the solution and provide the vehicle for reaching the desired end state architecture.

The reference text below is intended to facilitate consultant’s effort to describe potential migration scenarios for the proposed strategic solution (Exchange 2010). You can/should adjust the section contents below and add necessary customer specific information.

6.3.1 Migration and Transition Scenarios

This section discusses typical Exchange 2010 deployment scenarios that can be the basis for a lab or production implementation. The different scenarios are summarized below:

Exchange 2010 Greenfield Deployment – this is the simplest deployment option. The only prerequisite in this scenario is a healthy and properly configured Active Directory infrastructure. The Domain Controllers need to have the required updates installed before the Exchange 2010 servers can be rolled out.

Transitioning from Exchange 2007 – this scenario applies to customers who are already running on Exchange 2007 and would want to upgrade to Exchange 2010. The deployment planning will require additional considerations for the transition period.

Transitioning from Exchange 2003 – this scenario involves transitioning from an Exchange 2003 environment. This will look at customers who are currently running on Exchange 2003 and would want to skip Exchange 2007 and upgrade straight to Exchange 2010. Similar to the second scenario, additional planning is necessary for the co-existence of the servers and migration of the users.

6.4 Project Constraints

Guidelines for Documenting Constraints

Purpose: Identify any business, project or technical constraints that will need to be considered in design of the solution.

Responsibility: All

Length: As succinct as possible (one to two pages).

Guidelines: Identify those factors that will be critical to accurately designing the solution for all team perspectives.

In this section, provide description of existing project constraints and limitations that could affect the proposed architecture design and/or migration/transition process. These constraints and limitations could include (but are not limited to):

Budget constraints

Present here any budget limitations. Discuss the factors affecting the total cost of ownership (TCO) and return on investment (ROI) for the planned solution. Discuss the licensing model and explain how suggested licensing model allows customer to minimize


333Customer_Name3

the expenses. Describe the functional and feature limitations that could result from the budget constraints.

Timing constraints

Present the timing limitations that could affect proper execution of the project. Determine and present the project deadlines. Identify the major project milestones and present the high level project timeline allowing customer to meet the deadlines. This timeline should match the one presented in the project plan document. Describe the functional and feature limitations that could result from the budget constraints.

Resource constraints

Present the resource constraints for the project. Identify the project team and estimate the workforce required for successful completion of the project. Identify the hardware and other material resources required for the project, and the required dates of their availability. It is not necessary to present exact details for the hardware (such as number of servers), but it is necessary to identify which resources will be needed at which stage of the project.

This section should provide a smooth logical transition to the Appendix A describing project structure and MSF project approach model.

6.4.1 Budget constraints

6.4.2 Timing constraints

6.4.3 Resource constraints


333Customer_Name3

7 RISK EVALUATION AND ANALYSIS

Use this section to list and analyze all identified risk factors. These risks should be associated with the stages of the actual production deployment.

Justification: Early identification of risks enables the teams to begin managing and mitigating them.

This section presents the description of risk factors identified and assessed during the envisioning phase and analyzes their impact and suggested mitigation.

7.1 Risk ratings

The risk ratings used in this document are based upon the potential negative impact to the planned solution architecture. An exposure calculation is used to determine the category in which the issue falls. The exposure calculation takes the form of:

Exposure = Probability * Impact

Exposure is the product of probability and impact and is used for risk severity evaluation.

Low or medium exposure risks do not necessarily imply that the process in question is being performed optimally. Rather, it implies that the process is less likely to negatively impact stability by the process’ definition, or by current maturity level with that process.

Probability is the chance that the risk issue will actually occur and negatively impact the environment.

Probabilities from 1% to 99% are the standard risk probabilities. 100% is the probability that is used for the imminent (critical) risks. Actually, if a probability is 100%, the condition at hand is not a risk; it is a known issue that must be addressed via a workaround or resolution.

Impact is the degree of a negative impact of the risk when it occurs in the otherwise stable environment. Impact is measured in a 1 to 5 scale with 5 being the highest impact and 1 being the lowest. There is no 0 because 0 means no impact and therefore no risk at all.

To provide risk rating classification based on their exposure, we will use the following conventions:

Category Symbol Description

CriticalRisks that have an exposure of 500

(100% probability AND impact of 5)

High Risks that have an exposure of 375-499

Medium Risks that have an exposure of 50-374

Low Risks that have an exposure of 1-49

Table 19: Risk factor classification

The following subsection presents risk factors identified during the envisioning phase, provides brief issue description, explanation of the impact and probability, and recommended mitigation and contingency actions.


333Customer_Name3

This risk analysis information will be updated and extended during the subsequent phases of the project.

7.2 Risk factors

Issue

Exposure:

5x80%

400

Mitigation

Issue

Exposure:

5x40%

200

Mitigation

Issue

Exposure:

4x10%

40

Mitigation

Table 20: Risk factors, exposure, and mitigation


333Customer_Name3

8 APPENDIX A: PROJECT STRUCTURE

8.1 Team Roles and Responsibilities

Microsoft Consulting Services (MCS) recommends that the project team be organized according to the Microsoft Solutions Framework (MSF) Team Model. The MSF Team Model identifies major roles and their responsibilities during the phases of planning, implementing and deploying a business solution.

Figure 4: Team Model of the Microsoft Solutions Framework

The roles identified in the preceding figure do not imply that all projects require six people. Rather these are roles, not people. The roles must be assigned among the individuals on a project team. Each role brings a particular mindset that contributes to the overall quality of the effort.

Role Focus Skills Responsibility

Product Manager Customer satisfaction Good communication, knowledge of the business

Manage customer expectations, maintain the business case, research, promotion, launch

Program Manager On-time delivery, architecture, problem solving, identifying and resolving critical issues

Facilitation, project management, communication, writing, business model and IS standards knowledge

Specification management, tracking, coordination, sign off

Development A responsive, reliable, compliant product

Problem solving, development skills, deep technical knowledge

Feature design, construction, testing

Test Ensure all issues are known Ability to trace cause and effect, knack for breaking things, understanding of how things work

Testing strategy, testing, issue tracking

User Education A usable, supportable product that enhances end-user performance

User empathy, technical writing

Documentation design, terms definition, documentation, testing, baselining, training

Logistics Management

Smooth rollout, migration and operation

Facilitation, project management, communication, writing, operating environment expertise

Forecasting, preparation, support, ensure adequate infrastructure is available when needed

Table 21: Team roles and focus


333Customer_Name3

In order to cover the responsibilities of completing the project, the following roles have been assigned to the following individuals from Microsoft and Customer_Name. At later phases of the project, these roles may be explicitly transitioned to other team members who join the effort.

Resource Company Role

Name of Individual Customer_Name Executive Sponsor(s)

Name of Individual Customer_Name or Microsoft Services Product Manager(s)

Name of Individual Customer_Name or Microsoft Services Program Manager(s)

Name of Individual Customer_Name or Microsoft Services Development

Name of Individual Customer_Name or Microsoft Services Test

Name of Individual Customer_Name or Microsoft Services User Education

Name of Individual Customer_Name or Microsoft Services Logistics Management

Table 22: Resource assignments

One understands, from these role assignments, that Microsoft Services will deliver a solution architecture and migration recommendations. Customer_Name will provide adequate quality assurance and design review in order to sign-off on the recommendations document. Microsoft Services expects Autodesk team to provide quality management of the solution in terms of defining needs/requirements and managing expectations. Customer_Name will also need to provide all necessary information about their current environment.

8.2 Project Management Strategy

In the best possible world, all projects could be delivered good, fast and cheap. The reality is that, if any two of those attributes are successfully achieved, the third cannot be satisfied. Project management requires that a balance be struck among resources/cost, delivery dates and features (achieved results) of any project. Any of those three attributes can be managed in order to optimize, constrain, or accept its outcome. MCS recommends the project management strategy diagrammed in the following figure.

Figure 5: Project Management Trade-off Matrix

A desired upper limit on the project’s budget constrains the resources that can be applied. This limited group of people is asked to deliver the desirable features by a deadline set in the future. Their goal is to work creatively to deliver as much value as possible, but to meet the time deadline. In order to do this, the project team and customers must accept that some features might not be in the final product (for example, some functionality might not be deployed). The goal of this strategy is to understand the customer’s desires and needs, and rank them from most important to least. With this strategy, even important features may be left out of a specific stage of deployment if the benefit delivered by releasing the product outweighs the opportunity cost lost to a feature’s absence. This strategy is known as “shipping is a feature.”

Using the matrix in the preceding figure, other project management strategies can be devised, but they must adhere to the following rules:

One column must be checked in each row indicating how that attribute will be managed.

No column can be checked more than once, in order to avoid conflicting strategies.


333Customer_Name3

8.3 Phased Delivery of the Solution

The project solution is desired to be completed within the next several months. The company also has a limited budget to spend on the deployment of the solution and on infrastructure changes. Since the project aims to be completed in a short period of time, and only a limited number of people can be committed to the project, MCS recommends that the new system be designed and constructed according to the Microsoft Solutions Framework (MSF) Process Model. MSF represents a proven solution development approach that Microsoft has used to deliver hundreds of successful engagements. It provides well-defined phases that take into account development of requirements, architectural design, detailed software design, software development, system testing, and managed release cycles.

MSF organizes the solution approach into five distinct phases during the project lifecycle, as described below:

Envisioning: Envisioning involves creating a business vision and defining the scope of work necessary to bring the vision to reality.

Planning: Planning continues through the development of detailed functional requirements, system and application architectures, solution architecture and design, and a detailed project plan for the remainder of the project.

Development: The Development phase begins with the first iteration of development and culminates with the “functionality complete” milestone. For the infrastructure project this involves building and configuring servers and applications.

Stabilization: The Stabilization phase involves testing and acceptance. This includes both proof of concept lab testing and pilot deployment.

Deployment: The Deployment phase includes full deployment of the core technology and site components, transitioning of the project to operations and support, and obtaining final Customer approval of the project.

The chart below summarizes the 5 phases in the Microsoft Solutions Framework:

Figure 6: Process Model of the Microsoft Solutions Framework

The process applied by Microsoft Services in projects provides the context for making schedule, cost and feature trade-off decisions. The process is iterative, milestone driven and risk driven.


333Customer_Name3

Trade-off decisions are done by facilitating explicit agreement at four main milestones indicated by the diamonds in the preceding figure. The milestones are:

Vision/Scope ApprovedAgreement on long-range vision motivating the effort, as well as short-range scope of what will be accomplished. At this time, opportunities, risks and assumptions are shared and understood among the team members.

Project Plan ApprovedAgreement on solution architecture and implementation planning. Agreement on project deliverables, features and priorities, and the targeted release date. All team members buy into and commit to the delivery schedule.

Scope CompleteAgreement that all features have been built to specification, yet accepting that the solution is not fully implemented yet.

Release Readiness ApprovedAgreement that all necessary testing has been performed, all outstanding stability issues have been addressed, and that the support and operations organization is sufficiently prepared to deploy and manage the solution.

Deployment CompleteThe deployed solution should be providing the expected business value to the customer and the team should have effectively terminated the processes and activities it employed to reach this goal. The customer must agree that the team has met its objectives before it can declare the solution to be in production and close out the project. This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place.


333Customer_Name3

9 APPENDIX B: APPROVED STATEMENT OF WORK

Field experience proves that it is generally a good idea to include a copy of the customer approved SOW or work order document in the Vision and Scope document. This allows you to ensure the convergence between the SOW and the vision and scope presented in the current document, and to validate proper customer expectations.

For consistency purposes and to ensure that the presented Vision and Scope document conforms to the project goals and determined scope of work, we present here a copy of the approved Statement of Work document.


vision scope template example file - mof

Documents