<<Project Name>>

Vision/Scope

 

Customer Name 

 

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

 

Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

  

Version: 1.0

 

 

  

 

 

2002 Microsoft Corporation. All rights reserved.

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.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

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


 

Revision & Sign-off Sheet

Change Record

Date

Author

Version

Change Reference

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reviewers

Name

Version Approved

Position

Date

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Distribution

Name

Position

 

 

 

 

 

 

 

 

 

Document Properties

Item

Details

Document Title

Vision/Scope

Author

 

Creation Date

 

Last Updated

 

 

 


 

Table of Contents

 TOC \o "1-3" \h \z

Business Opportunity. PAGEREF _Toc12669119 \h 3

Opportunity Statement PAGEREF _Toc12669120 \h 3

Vision Statement PAGEREF _Toc12669121 \h 3

Benefits Analysis. PAGEREF _Toc12669122 \h 3

Solutions Concept PAGEREF _Toc12669123 \h 4

Goals, Objectives, Assumptions, and Constraints. PAGEREF _Toc12669124 \h 4

Usage Analysis. PAGEREF _Toc12669125 \h 5

User Profiles. PAGEREF _Toc12669126 \h 5

Usage Scenarios. PAGEREF _Toc12669127 \h 5

Requirements. PAGEREF _Toc12669128 \h 5

Business Requirements. PAGEREF _Toc12669129 \h 6

User Requirements. PAGEREF _Toc12669130 \h 6

Operational Requirements. PAGEREF _Toc12669131 \h 6

System Requirements. PAGEREF _Toc12669132 \h 6

Scope. PAGEREF _Toc12669133 \h 6

Feature/Function List PAGEREF _Toc12669134 \h 6

Out of Scope. PAGEREF _Toc12669135 \h 6

Version Release Strategy. PAGEREF _Toc12669136 \h 7

Acceptance Criteria. PAGEREF _Toc12669137 \h 7

Operational Criteria. PAGEREF _Toc12669138 \h 7

Solution Design Strategies. PAGEREF _Toc12669139 \h 8

Architectural Design Strategy. PAGEREF _Toc12669140 \h 8

Technical Design Strategy. PAGEREF _Toc12669141 \h 8

 

 


 

[Introduction to the Template

 

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.

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

         Business Opportunity: a description of the customerís situation and needs

         Solutions Concept: the approach the project team will take to meet the customerís needs

         Scope: the boundary of the solution defined though the range of features and functions, what is out of scope, a release strategy, and the criteria by which the solution will be accepted by users and operations

         Solution Design Strategies: the architectural and technical designs used to create the customerís solution

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 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.}]

 

 


 

Business Opportunity

[Description: The Business Opportunity section contains the statement of the customerís situation. It is expressed in business language, not technical terms. This section should demonstrate Microsoftís understanding of the customerís current environment and its desired future state. This information is the overall context for the project.]

Opportunity Statement

[Description: The Opportunity Statement section describes the customerís current situation that creates the need for the project. It may contain a statement of the customerís opportunity and the impact of capitalizing on that opportunity (product innovation, revenue enhancement, cost avoidance, operational streamlining, leveraging knowledge). It may contain 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). It should include a statement that connects the customerís opportunity/problem to the relevant business strategy and drivers. The Opportunity Statement is written concisely using a business executiveís voice.

 

Justification: The Opportunity Statement demonstrates that Microsoft understands 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.]

<<Begin text here>>

 

Vision Statement

[Description: The Vision Statement section clearly and concisely describes the future desired state of the customerís environment once the project is complete. This can be a restatement of the opportunity; 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.]

<<Begin text here>>

 

Benefits Analysis

[Description: The Benefits Analysis section describes how the customer will derive value from the proposed solution. It connects 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:

 

         Business Goals and Objectives

         Business Metrics

         Business Assumptions and Constraints

         Benefits Statement

 

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

<<Begin text here>>

 

Solutions Concept

[Description: A Solutions Concept provides a general description of the technical approach the project team will take to meet the customerís needs. This includes an understanding of the users and their needs, the solutionís features and functions, acceptance criteria, and the architectural and technical design approaches.

 

Justification: The Solution Concept provides teams with limited but sufficient detail to prove the solution to be complete and correct; to perform several types of analyses including feasibility studies, risk analysis, usability studies, and performance analysis; and to communicate the proposed solution to the customer and other key stakeholders.]

Goals, Objectives, Assumptions, and Constraints

[Description: The Goals, Objectives, Assumptions, and Constraints section contains the following components that define the productís parameters:

 

 

The solution Goals and Objectives are initially derived from the business and technical goals and objectives that are developed during the opportunity phase and confirmed during the envisioning phase.

 

Assumptions and Constraints may be derived from the productís functionality, as well as research regarding the customerís environment.

 

Justification: The Goals and Objectives articulate both the customerís and teamís expectations of the solution and can be converted into performance measurements. Assumptions attempt to create explicit information from implicit issues and to point out where factual data is unavailable. Constraints place limits on the creation of boundaries and decision-making.]

<<Begin text here>>

 

Usage Analysis

[Description: The Usage Analysis section lists and defines the solutionís users and their important characteristics. It also describes how the users will interact with the solution. This information forms the basis for developing requirements.]

User Profiles

[Description: The User Profile describes the proposed solutionís users and their important characteristics. The users are identified in groups ó usually stated in terms of their functional areas. Often users are from both the IT (help desk, database administration, etc.) and business (accounting, warehouse, procurement, etc.) areas of the customerís organization. The important characteristics identify what the users are doing that the solution will facilitate. These characteristics can be expressed in terms of activities: for example, the accounting user receives invoices and makes payments to suppliers.

 

This section should contain a level of user profile information that enables the identification of unique requirements.

 

Justification: Initially, User Profiles enable the development of usage scenarios (next section). Beyond that, User Profiles provide the project teams with vital requirements information. A complete set of User Profiles ensures that all high-level requirements can be identified. The product team uses these profiles as input when developing the Feature/Function List. The development team uses these profiles as input to its architecture and technology design strategies. The user education team uses these profiles to establish the breadth of their work.]

<<Begin text here>>

 

Usage Scenarios

[Description: Usage Scenarios define the sequences of activities the users perform within the proposed solutions environment. This information is comprised of a set of key events that will occur within the usersí environment. These events should be described by their objectives, key activities and their sequences, and the expected results.

 

Justification: Usage Scenarios provide vital information to identify and define the solutionís user and organizational requirements, the look and feel of user interfaces, and the performance users expect of the solution.]

<<Begin text here>>

 

Requirements

[Description: Requirements identify what the solution must do. These Requirements can be expressed in terms of functionality (for example, a registration Web site solution will allow the users to register for events, arrange for lodging, etc.) as well as the rules or parameters that apply to that functionality (for example, the user can only register once, and must stay in lodging approved by the travel department).

 

Requirements exist at both the user level and the organizational level.

 

Justification: User and Organizational Requirements are the key input to developing product scope and design strategies. Requirements are the bridge between the usage analysis and solution description. A complete statement of Requirements demonstrates that Microsoft understands its customerís needs. The statement also becomes the baseline for more detailed technical documentation in the planning phase. Good Requirements analysis lowers the risk of downstream surprises.]

Business Requirements

<<Begin text here>>

 

User Requirements

<<Begin text here>>

 

Operational Requirements

<<Begin text here>>

 

System Requirements

<<Begin text here>>

 

Scope

[Description: The Scope places 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.]

Feature/Function List

[Description: The Feature/Function List section contains an expression of the solution stated in terms of Features and Functions. It identifies and defines the components required to satisfy the customerís requirements.

 

Justification: The Feature/Function List enables the customer and project team to understand what the project will develop and deliver into the customerís environment. It is also the input to the Architectural and Technical Design Strategies.]

<<Begin text here>>

 

Out of Scope

[Description: The Out of Scope section lists and defines a limited set of features and functions excluded from a product or solution óthat is, the features and functions that fall outside its boundaries. It does not list everything that is Out of Scope; it only lists and defines features and functions that some users and other stakeholders might typically associate with a type of solution or product.

 

Justification: Out of Scope documentation helps to clarify the solution scope and explicitly states what will not be delivered in the solution.]

<<Begin text here>>

 

Version Release Strategy

[Description: The Version Release Strategy section describes the strategy by which the project will deliver incremental sets of features and functions of the customerís solution in a series of releases that build upon each other to completion.

 

Justification: The Version Release Strategy enables the customer to plan for the orderly implementation of the solution, including the acquisition of the required infrastructure to support the solution. It also describes how Microsoft will provide the customer with a usable set of functions and features as soon as possible.]

<<Begin text here>>

 

Acceptance Criteria

[Description: 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 communicate to the project team the terms and conditions under which the customer will accept the solution.]

<<Begin text here>>

 

Operational Criteria

[Description: Operational Criteria define the conditions and circumstance 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.]

<<Begin text here>>

 

 

Solution Design Strategies

Architectural Design Strategy

[Description: The Architectural Design Strategy describes 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.]

<<Begin text here>>

 

Technical Design Strategy

[Description: The Technical Design Strategy documents the application of specific technologies to the Architectural Design. It is a high-level description of the key products and technologies to be used in developing the solution.

 

Justification: A Technical Design Strategy identifies the specific Microsoft technologies that will be applied to the solution and demonstrates their benefits to the client.]

<<Begin text here>>