Vision Scope Template Example File - MOF

Vision Scope
Exchange Delivery Planning Services
Prepared for Customer_Name Wednesday, 2 May 2012 Version 1
Prepared by EDPS Team
Contributors EDPS Delivery Partner
Microsoft Confidential
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 ii
Vision Scope, Exchange Delivery Planning Services, Version 1 Draft Prepared by EDPS Team "Document1" last modified on 2 May. 12, Rev 2
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 iii
Table of Contents
1 2 3 4 Introduction .................................................................................................................................... 2 Problem Statement ........................................................................................................................ 3 Business Statement and Goals .................................................................................................... 4 Project Vision and Scope .............................................................................................................. 6 4.1 Vision Statement....................................................................................................................... 6 Benefits Analysis ................................................................................................................. 6
4.1.1 4.2
Scope of Project ....................................................................................................................... 6 Project Phases and Objectives In Scope ............................................................................ 7 Project Phases and Objectives Out of Scope ..................................................................... 8 Project Milestones and Deliverables ................................................................................... 8 Assumptions and Dependencies......................................................................................... 9
4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.4 5
Acceptance Criteria ................................................................................................................ 10 Conditions of Satisfaction ....................................................................................................... 10
Project Requirements .................................................................................................................. 11 5.1 Solution Requirements ........................................................................................................... 11 Business Requirements .................................................................................................... 11 Operational Requirements ................................................................................................ 12 Technical Requirements ................................................................................................... 12
5.1.1 5.1.2 5.1.3 5.2
Availability Requirements ....................................................................................................... 13 Availability Definitions ....................................................................................................... 13 Identified Availability Requirements .................................................................................. 14
5.2.1 5.2.2 5.3
SLAs and OLAs ..................................................................................................................... 14 Determining Service Level Agreements ............................................................................ 14 Service Level Agreements derived from the Solution Requirements ............................... 16 Service dependencies ....................................................................................................... 18 Operating Level Agreements ............................................................................................ 19
5.3.1 5.3.2 5.3.3 5.3.4 5.4
Quality of Service: Multi-Tier Service Levels Model ............................................................... 20 Service Level Tier Definitions ............................................................................................ 20 Service Mapping to Service Level Tiers ............................................................................ 21
5.4.1 5.4.2 6
Solution Design Strategies ......................................................................................................... 22 6.1 Current Environment............................................................................................................... 22 Users ................................................................................................................................. 22
6.1.1 6.2 6.3
Architectural Design Strategy ................................................................................................. 22 Deployment Design Strategy .................................................................................................. 24 Migration and Transition Scenarios ................................................................................... 24
6.3.1 6.4
Project Constraints ................................................................................................................. 24 Budget constraints............................................................................................................. 25

Page iv
6.4.1
6.4.2 6.4.3 7
Timing constraints ............................................................................................................. 25 Resource constraints ........................................................................................................ 25
Risk Evaluation and Analysis ..................................................................................................... 26 7.1 7.2 Risk ratings ............................................................................................................................. 26 Risk factors ............................................................................................................................. 27
Appendix A: Project Structure ................................................................................................... 28 8.1 8.2 8.3 Team Roles and Responsibilities ........................................................................................... 28 Project Management Strategy ................................................................................................ 29 Phased Delivery of the Solution ............................................................................................. 30
Appendix B: Approved Statement of Work ............................................................................... 32
Page v
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, customers

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 customers 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, upfront 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 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.
Page 2
PROBLEM STATEMENT
Guidelines for a Problem Statement Purpose: Responsibility: Length: Guidelines: Establish the motivation for the project Product Management Less than one page, ideally 2-3 paragraphs 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.
Page 3
BUSINESS STATEMENT AND GOALS

In this section, write a statement of the customers situation. It should be expressed in business language, rather than technical terms. The Business Statement is written concisely using a business executives voice. This section should demonstrate that you understand the customers current environment and its desired future state. This information is the overall context for the project. When describing the customers current situation that creates the need for the project, you may include a statement of the customers 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 customers 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 customers opportunity/problem to the relevant business strategy and drivers. This section will start with a description of the customers 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 customers situation from the business point of view and provides the project team and other readers with the strategic context for the remaining sections.
Page 4
Page 5
4
4.1
PROJECT VISION AND SCOPE

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 customers 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. 2. 3. 4. Business Goals and Objectives Business Metrics Business Assumptions and Constraints Benefits Statement
Justification: Benefits Analysis demonstrates that you sufficiently understand the customers situation. It also defines the customers 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
Page 6
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 SLAs; 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, preconfiguring 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
Page 7
Objective 1 description Objective 2 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 Objective 1 description Objective 2 description Rational 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:
# 1. 2. 3. 4. 5. 6. 7.
Page 8
Project Milestones End state architecture design approved Migration plan approved Test lab built and configured Proof of Concept testing completed Active Directory and network prepared for Exchange 2010 deployment Exchange 2010 servers deployed
Timeline estimate
Rational
Table 3: Planned project milestones
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:
# 1. 2. 3. 4. 5.
Table 4: Planned document deliverables for the project
Document Deliverable Project Plan Vision and Scope document Functional Specification (Architecture Design document) Proof of Concept Lab design
Format Microsoft Project 2007 Microsoft Word 2007 or Adobe PDF Microsoft Word 2007 or Adobe PDF Microsoft Word 2007 Microsoft Visio 2007
Rational
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.
Page 9
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 customers 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 customers 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 solutions 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.
Page 10
5
5.1
PROJECT REQUIREMENTS
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 customers 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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Requirement 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
Page 11
Rational
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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Requirement 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 Rational
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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Requirement 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 Rational
Table 7: Technical requirements
Page 12
5.2
5.2.1
Availability Requirements
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 dont 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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Service Availability level 99.9% 99.99%
Table 8: Service Availability levels
Unplanned downtime only Unacceptable Required
Both planned and unplanned downtime Required Desired / optional
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;
Page 13
99% (two nines) means 87.6 hours, or 3.65 days, of downtime per year; 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:
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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Requirement 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) Rational
Table 9: General availability requirements
5.3
5.3.1
SLAs and OLAs

Determining Service Level Agreements
Service Level Agreements (SLAs) 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.
Page 14
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:
Lost mail No service
Time
T0
T1
T2
T3
Last good backup
System crash
Dial-tone service restored
Full service restored
Service Level Agreements Recovery Point Objective: Recovery Time Objective: RPO = T1 T0 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 SLAs. 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): Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
SLA objective Single mailbox recovery Single Single server database recovery recovery (storage remained intact) 2 hours 0 (messages accumulate in the queues) 1-2 hours Data recovery (servers and storage devices with backup remain intact) 2 hours Storage recovery (storage devices and all data are lost) 2 24 hours depending on data replication and backup schedule 2-8 hours (time needed to provide new storage and present it to servers) Site recovery (catastrophic disaster, all servers and storage lost at the site) 8 - 24 hours depending on data replication and/or backup technologies used Strongly determined by technology used, e.g. 10-15 min for the cluster or 2-4 hours for a stand-alone server
RPO
0 (every message can (how much data can be recovered) be lost) RTO for service 30-60 min (non-critical failure since (how fast should service be restored) service for other users is not interrupted) RTO for data 4-6 hours (non-critical failure since (how fast should access to historical service for other users is data be restored) not interrupted)
2 hours
15-30 min (time needed to provide storage for dial-tone database)
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 SLAs 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:
Page 15
Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Failure Mode RTO Server Node LUN / Physical Corruption Single Array / Full Storage Site RPO Server Node DB LUN Log LUN Single Array / Full Storage Site SCC + VSS Clones < 5 min < 1 hour Days Days 0 0 Point in Time 24+ hours 24+ hours SCC + Sync Replication N/A use SCC 15 min 1 hour < 15 min < 15 min 0 0 0 / Point in Time 0 0 CCR (1 site) < 5 min < 5 min < 5 min Days 1 Log 0 1 Log 1 Log Geographically Dispersed CCR < 5 min < 5 min < 5 min Hour 1 Log 0 1 Log 1 Log CCR (in-site) + SCR (out-site) N/A use CCR N/A use CCR N/A use CCR < 1 hour 1 Log N/A use CCR 1 Log 1 Log 1 Log
24+ hours 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 (SLAs) 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 SLAs originate from the identified and quantified business and operational requirements as listed above. The general SLAs typically come from business requirements. They can and should be defined for different components of the messaging services: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
SLA objective 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) Internal messaging External messaging (e-mail within the org) (e-mail out of the org) 5 min 2 min External client access Outlook Voice Access (from public network) N/A N/A (same as e-mail) 2 hours Voice mail 30 min
30 min
60 min
60 min
2 hours
4 hours
N/A
N/A
N/A (data not affected)
4 hours
Table 12: General Service Level Agreements for the messaging services
Page 16
The more detailed SLAs 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: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Server role Mailbox Server Client Access Server Hub Transport Server Edge Transport Server Unified Messaging Server Requirement RTO for mailbox server recovery RTO for mailbox data recovery RTO for service for internal clients RTO for service for external clients Recovery of internal mail flow Recovery of external mail flow OVA, voicemail and fax flow recovery SLA value 15 min/server 2 hours/database 2 hours 4 hours 2 hours 4 hours 4 hours
Table 13: SLA requirements by server role
However, the general SLAs, 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 SLAs 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 Single server database recovery 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.
Page 17
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 (SLAs) as well as interdepartmental operating level agreements (OLAs). Therefore it is important to distinguish between service level agreements (SLAs) which constitute the agreements between service provider and the client, and operating service agreements (OLAs) that constitute the agreements between different providers. SLA strongly depends on OLAs 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 doesnt make sense to set the server recovery SLA for the requesting department to less than 4 hours. Of course, there might be additional OLAs associated with additional links in the OLA dependencies chain. The following figure illustrates how the resulting SLA depends on the chain of OLAs hat affect the overall service recovery time:
Page 18
SLA & OLA dependencies: Messaging service recovery

Recovering server Joining domain Systems Operations
Joining network
Messaging
Messaging
Restoring service SLA approved OLA approved
Networking Operations Server build Windows Server
Users
Figure 3: SLA and OLA dependencies
Provisioning Hardware hardware Operations
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 SLAs for the particular service.
5.3.4
Operating Level Agreements
Besides the general Service Level Agreements, there might be various Operating Level Agreements (OLAs) defined for specific operational tasks. The two distinct types of OLAs are: Internal OLAs defined as sub-components of the general messaging service SLA. Within the messaging service scope of agreements, the internal OLAs can be, for example, backup and recovery times for mailbox databases or individual mailboxes, or server provisioning time for dial-tone disaster recovery. Internal OLAs contribute to the general SLA for the affected messaging role. Interdepartmental OLAs (based on service dependencies) determining service availability for all environmental dependencies that affect messaging service and therefore also contribute to the messaging SLAs. 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 customers messaging environment for different levels of mail data recovery: Note: The requirements listed in the tables below are samples. Replace them with the actual requirements obtained from the customer.
Operating Area Server Server provisioning Restore Time Backup Time Database N/A Operating Level Mailbox N/A Message N/A
Page 19
Online Maintenance time Offline Maintenance time Cluster failover time Restore of CAS IIS directories Route convergence N/A N/A
Table 15: Internal OLAs within the scope of SLAs for the messaging service
The following table lists the identified internal Operating Level Agreements which apply to the customers environmental dependency services:
Environmental Dependency 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) Requirement OLA value
Table 16: Interdepartmental Operating Level Agreements for Exchange Environmental Dependencies
5.4
5.4.1
Quality of Service: Multi-Tier Service Levels Model

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 99.5% Server RTO: availability Server level 99.95% 30 min RTO: Datacenter level 4 hours RTO: Site level 2 days
Mission Critical
Business Critical
Corporate standard
Failure severely affects the entire company and puts the whole company business at risk Failure severely impacts the single department / business unit and puts the affected business at risk Failure impacts the service
99%
99.9%
2 hours
1 day
3 days
95%
99%
4 hours
3 days
7 days
Page 20
Business standard
functionality but is not critical to the company business Failure impacts the single business 90% but is not critical to the main functionality
95%
1 day
7 days
1 month
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 SLAs. 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 Mission Critical Business Critical Corporate standard Network services General and HQ connectivity DNS services Site connectivity DHCP services WINS services Network segment connectivity Directory services Global Catalog Root Domain DCs Site level DCs Child domain DCs Monitoring servers Unified Communications E-mail functionality Fax functionality Mobility Voice mail Live Meeting Instant Messaging Collaboration portals Corporate portal Business unit portals Site libraries
Business standard
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.
Page 21
6
6.1
SOLUTION DESIGN STRATEGIES

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 rd 3 -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 rd 3 -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 consultants 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.
Page 22
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.
Page 23
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 consultants 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: Length: All
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
Page 24
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 6.4.2 6.4.3
Budget constraints Timing constraints Resource constraints
Page 25
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 Critical Symbol Description Risks that have an exposure of 500 (100% probability AND impact of 5) Risks that have an exposure of 375-499
High
Medium
Risks that have an exposure of 50-374
Low
Table 19: Risk factor classification
Risks that have an exposure of 1-49
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.
Page 26
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
Page 27
8
8.1
APPENDIX A: PROJECT STRUCTURE

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 Product Manager Focus Customer satisfaction Skills Good communication, knowledge of the business Facilitation, project management, communication, writing, business model and IS standards knowledge Problem solving, development skills, deep technical knowledge Ability to trace cause and effect, knack for breaking things, understanding of how things work User empathy, technical writing Responsibility Manage customer expectations, maintain the business case, research, promotion, launch Specification management, tracking, coordination, sign off
Program Manager
On-time delivery, architecture, problem solving, identifying and resolving critical issues
Development
A responsive, reliable, compliant product Ensure all issues are known
Feature design, construction, testing Testing strategy, testing, issue tracking
Test
User Education
A usable, supportable product that enhances end-user performance Smooth rollout, migration and operation
Documentation design, terms definition, documentation, testing, baselining, training Forecasting, preparation, support, ensure adequate infrastructure is available when needed
Logistics Management
Facilitation, project management, communication, writing, operating environment expertise
Table 21: Team roles and focus Page 28

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 Name of Individual Name of Individual Name of Individual Name of Individual Name of Individual Name of Individual Name of Individual
Table 22: Resource assignments
Company Customer_Name Customer_Name or Microsoft Services Customer_Name or Microsoft Services Customer_Name or Microsoft Services Customer_Name or Microsoft Services Customer_Name or Microsoft Services Customer_Name or Microsoft Services
Role Executive Sponsor(s) Product Manager(s) Program Manager(s) Development Test User Education Logistics Management
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 projects 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 customers 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 features 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.
Page 29
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.
Page 30
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 Approved Agreement 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 Approved Agreement 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 Complete Agreement that all features have been built to specification, yet accepting that the solution is not fully implemented yet. Release Readiness Approved Agreement 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 Complete The 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.
Page 31
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.
Page 32

Vision Scope Template Example File - MOF

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vision Scope Template Example File - MOF

Uploaded by

Copyright:

Available Formats

Vision Scope

Exchange Delivery Planning Services

Prepared for Customer_Name Wednesday, 2 May 2012 Version 1

Prepared by EDPS Team

Contributors EDPS Delivery Partner

Revision and Signoff Sheet

4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.4 5

Acceptance Criteria ................................................................................................................ 10 Conditions of Satisfaction ....................................................................................................... 10

5.1.1 5.1.2 5.1.3 5.2

5.2.1 5.2.2 5.3

5.3.1 5.3.2 5.3.3 5.3.4 5.4

6.1.1 6.2 6.3

Project Constraints ................................................................................................................. 24 Budget constraints............................................................................................................. 25

Timing constraints ............................................................................................................. 25 Resource constraints ........................................................................................................ 25

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

Problem and Business Statements: A description of the project motivation, customers

BUSINESS STATEMENT AND GOALS

PROJECT VISION AND SCOPE

As succinct as possible (one to two pages).

Project Phases and Objectives In Scope

Objective 1 description Objective 2 description

Table 1: Business Objectives In Scope

Project Phases and Objectives Out of Scope

Table 2: Business Objectives Out of Scope

Project Milestones and Deliverables

Table 3: Planned project milestones

Assumptions and Dependencies

Table 5: Business requirements

Table 6: Operational requirements

Table 7: Technical requirements

Unplanned downtime only Unacceptable Required

Both planned and unplanned downtime Required Desired / optional

Identified Availability Requirements

Table 9: General availability requirements

SLAs and OLAs

Last good backup

Dial-tone service restored

Full service restored

Figure 1: RPO and RTO definitions for messaging service

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

2-4 hours 1-2 hours

24+ hours 1 Log

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

Service Level Agreements derived from the Solution Requirements

N/A (data not affected)

Table 13: SLA requirements by server role

Figure 2: Typical IT Service Dependencies

SLA & OLA dependencies: Messaging service recovery

Restoring service SLA approved OLA approved

Networking Operations Server build Windows Server

Provisioning Hardware hardware Operations

Operating Level Agreements

Quality of Service: Multi-Tier Service Levels Model

Table 17: Service Level Tiers Model

Service Mapping to Service Level Tiers

Table 18: Service Offerings Tiers: example

SOLUTION DESIGN STRATEGIES

Architectural Design Strategy

Deployment Design Strategy

Migration and Transition Scenarios

As succinct as possible (one to two pages).

6.4.1 6.4.2 6.4.3

Budget constraints Timing constraints Resource constraints