04/03/2018 Chapter 2 - Envisioning Phase

Chapter 2 - Envisioning Phase

On This Page
Goals for the Envisioning Phase
Setting Up a Team
Defining the Project Structure
Defining the Business Goals
Assessing the Current Situation
Creating the Vision and Defining Scope
Defining High-level Requirements and User Profiles
Developing the Solution Concept
Assessing Risk
Closing the Envisioning Phase
Key Milestone: Vision/Scope Approved

Goals for the Envisioning Phase

Figure 2.1: The Envisioning Phase in the MSF Process Model

During the Envisioning Phase, the first phase defined in the MSF Process Model, the team clarifies the business problem or
opportunity that the solution must solve. It completes tasks and creates deliverables to meet the goal of this phase to create
a high-level view of the project's goals, constraints, and solution. This phase culminates in the Vision/Scope Approved
Milestone, indicating team and customer agreement on the purpose and direction of the project.

Note: The "customer" is the individual or individuals who expect to gain business value from the solution, and is also known
as the business sponsor. The CFO, representing the corporation, might be the customer for a solution to be implemented by
a project team within the IT organization.

The tasks summarized in Table 2.1 need to be completed during the Envisioning Phase. This project guide describes the
processes and roles required to accomplish them. Detailed information specific to each migration project about each task,
especially technical information, is provided in the migration guide for that project.

Table 2.1 Major Envisioning Phase Tasks and Owners

Major Tasks Owners

Setting up a team Product

Senior management determines that a project is viable and selects a Program Manager whose first task Management
is to assemble a project team that represents all six MSF team roles.
Program
Management

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 1/14
04/03/2018 Chapter 2 - Envisioning Phase

Defining the project structure Program

The team creates the project structure, which describes the administrative structure for the project team Management
going into the Planning Phase. It includes standards the team will use to manage and support the
project.

Defining the business goals Product

The team identifies the business problems or opportunities in order to determine the objectives for the Management
solution.

Assessing the current situation Program

The team assesses the current state of the business and performs a gap analysis to help identify a path Management
toward the desired state of the business.

Creating the vision and defining the scope for the project Product
The team creates a shared and clearly articulated vision statement that guides the team toward its Management
business goals. The team also identifies the scope of the project by defining what will and will not be Program
included. Management

Defining high-level requirements and user profiles Product

The team determines the needs of each key stakeholder, sponsor, and end user in order to provide input Management
regarding the formation of the solution concept, to provide criteria for evaluating the vision/scope User
document, and to provide a basis for more detailed requirements in the Planning Phase. Education

Developing the solution concept Program

The team transforms the high-level requirements into an initial concept of how the solution solves the Management
business problem. The solution concept serves as a baseline and sets the stage for the more formal
design of the solution.

Assessing risk Program

The team proactively identifies project risks and creates plans to deal with them during the Envisioning Management
Phase. It continues this recurring process throughout the project.

Closing the Envisioning Phase Project team

The team completes the approval process for the Vision/Scope Approved Milestone by formalizing the
documentation that records the results of its tasks and presenting it to management for approval.

Top of page
Setting Up a Team
In order to transform overall business goals into a clear vision for the project, an organization needs to assemble a team,
based on MSF roles, and with defined skill sets appropriate to the project. Once assembled, this team defines the vision and
scope that together provide a clear direction for the project and set expectations within the organization.

Defining Roles and Responsibilities

As discussed in the Team Model overview, six key quality goals drive the team and define the focus of each team role.
Although the team as a whole is responsible for the projects success, each of the interdependent, multidisciplinary roles
focuses on a distinct quality goal to ensure that responsibility is taken for implementing different aspects of the project.

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 2/14
04/03/2018 Chapter 2 - Envisioning Phase

Figure 2.2: Team role clusters and functional areas

Each MSF role identifies a combined set of functional areas and their associated responsibilities. The roles do not imply or
suggest any kind of organization chart or set of job titles because these vary widely by organization and team. A role, or
cluster, may be filled by one or many people. The number of people assigned to the role depends on the size and complexity
of a project as well as the skills required to fulfill the responsibilities of the functional areas. Most often, the roles are
distributed among different groups within the IT organization, and sometimes they are distributed among the business user
community, external consultants and partners. The key is to clarify which team member is fulfilling which role cluster and its
associated functions, responsibilities, and contributions.

Table 2.2 lists each role with its goal and identifies its key functional areas and project responsibilities.

Table 2.2 Roles, Goals, Functional Areas, and Responsibilities

Role and Goal Functional Area Responsibilities

Product Management: satisfy customers Business value Act as customer advocate

Marketing Drive shared project vision/scope

Customer advocacy Manage customer requirements

definition
Product planning
Develop and maintain business case

Manage customer expectations

Drive features versus schedule versus

resources tradeoff decisions

Manage marketing, evangelizing, and

public relations

Develop, maintain, and execute the

communications plan

Program Management: deliver the solution within Project management Drive development process to ship
project constraints product on time
Solution architecture
Manage product specification primary
Process assurance project architect

Administrative services Facilitate communication and

negotiation within the team
https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 3/14
04/03/2018 Chapter 2 - Envisioning Phase

Maintain the project schedule and report

project status

Drive implementation of critical trade off

decisions

Develop, maintain, and execute the

project master plan and schedule

Drive and manage risk assessment and

risk management

Development: build to specification Technology consulting Specify the features of physical design

Implementation Estimate time and effort to complete

architecture and each feature
design
Build or supervise building of features
Application
development Prepare product for deployment

Infrastructure Provide technology subject matter

development expertise to the team

Test: approve for release only after all product Test Planning Ensure all issues are known
quality issues are identified and addressed
Test engineering Develop testing strategy and plans

Test reporting Conduct testing

User Experience: enhance user effectiveness Accessibility Act as user advocate on team

Internationalization Manage user requirements definition

User advocacy Design and develop performance

support systems
Training/support
material Drive usability and user performance
enhancement trade-off decisions
Usability research and
testing Provide specifications for help features
and files
User interface design
Develop and provide user training

Release Management: achieve smooth deployment Infrastructure Act as advocate for operations, support,
and ongoing operations and delivery channels
Support
Manage procurement
Operations
Manage product deployment
Logistics
Drive manageability and supportability
Commercial release trade-off decisions
management
Manage operations, support, and
delivery channel relationship

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 4/14
04/03/2018 Chapter 2 - Envisioning Phase

Provide logistical support to the project

team

Product Management Role

The Product Management Role acts as the customer advocate to the project team by ensuring that the team addresses the
customers requirements, concerns, questions, and feedback throughout the project. The Product Manager also acts as the
teams liaison to the customer, handling high-level communication and managing the customers expectations. Product
managers must understand the business needs of the solution, including operations, business processes, and policies.

Program Management Role

The Program Management Role is responsible for leading the team in making decisions and driving the project schedule and
project plan. Program Management owns responsibility for all internal team communication and ensuring adherence to
corporate and project standards.

The person or persons fulfilling the role of Program Management should also have an understanding of technical issues at a
level sufficient to drive team decisions. This role keeps the team focused on the path to the solution and does not necessarily
need to have in-depth knowledge of every skill set for the project. The Program Management Role also drives the
negotiation process during decision-making and ensures that there is team consensus on all trade-off decisions.

Development Role

The Development Role is responsible for designing, building, and unit testing the baseline code. This includes items such as
the interface, core components, and database schema, as well as integration with other systems.

As builders, development drives the architecture and physical design of the solution, provides low-level solution and feature
design, estimates the effort required to deliver on that design, constructs functional prototypes to validate decision-making
and mitigate development risks, and then builds the solution. In addition to being the solution builders, development serves
on the team as the technology consultant. As technology consultant, development provides recommendations about the use
of specific technologies.

Development estimates its own effort and schedule because it works daily with all developmental contingency factors. MSF
refers to this concept as "bottom-up estimating," and it is a fundamental part of the MSF philosophy. The goals are to
achieve a more accurate schedule, increase the accountability of those providing the estimates, and achieve a high quality of
work performance.

Test Role

The test role is responsible for testing the components, architecture, and associated documentation against the functional
specification and ensuring that it meets requirements. In many ways, the testing role is the most vital part of the overall
project. If unable to test, the solution team never truly knows if everything works properly. Nor will it be able to address
issues prior to release.

In migration projects, testing is especially critical. It is frequently insufficient for the migrated environment to merely behave
in accordance with the specification for the initial environment. The migrated environment must behave identically
(sometimes referred to as bug-for-bug compatibility"). The baselining task (identifying the initial environment specifications)
is the key to ensuring that the migrated environment performs interchangeably with the old environment while still providing
the new capabilities that justified the effort required to perform the migration.

Just as different types of development roles exist, there are various test roles to conduct different types of tests. These
include tests for security, performance, compatibility, stress, usability, and other tests as required. Specific skill sets required
for these roles must be comparable to those of the developers working on the same project.

User Experience Role

The User Experience Role advocates for the end user. This role defines the requirements for functionality from the end user
perspective. Typically, this role is associated with graphic and information design, usability, and interface development.

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 5/14
04/03/2018 Chapter 2 - Envisioning Phase

However, other key functions this role plays are often forgotten, such as development of help documentation, training, and
communication materials such as frequently asked questions (FAQs), and support documentation.

Migration projects place an increased emphasis on these often overlooked functions. For a migration to succeed, training
and documentation must be provided to help users understand and accommodate the differences between the pre-
migration and post-migration environments, in addition to providing documentation on use and operations within the new
environment.

Release Management Role

The Release Management Role participates in the design process to help ensure that the completed solution is deployable,
manageable, and supportable. This role serves as the advocate for operations, product support, help desk, and other delivery
channel organizations in its focus on smooth deployment and ongoing management. Release Management directly
represents the operations perspective from the beginning on the solution development team.

Release Management is responsible for coordinating the activities necessary to ensure a successful rollout and for defining
and documenting life cycle management strategies and processes. Team members filling this role act as the IT operations
support advocate on the team. This includes preparing the development, testing, and staging environments and deploying
the solution.

Release Management must be familiar with the operational environment, including technical support and help desk. This
includes an understanding of the impact the solution will have on the legacy environment.

Assigning Roles
Although every role should be represented during the Envisioning Phase, it is not necessary to assemble the entire project
team at this point, nor is it necessary yet for every team member to be fully dedicated to the project. Every role, however,
should have an identified leader during the Envisioning Phase, and an effort should be made to dedicate the leader's full
time to the project from the very beginning. In reality, it is not always possible for all team members to fully disengage from
their other responsibilities before beginning work on a new project.

Follow these guidelines when assigning people to roles:

If possible, the Product Management and Program Management roles should be fully dedicated at this point.

Although the Development lead can be wrapping up other projects during the Envisioning Phase, if possible, this
person should be fully dedicated to this project. Expect to add additional team members to the Development Role
during the Developing Phase.

The Test lead can be assigned to other projects during the Envisioning Phase if necessary, but should be available to
sign off on important decisions. If necessary, add additional team members to the Test Role during the Developing
Phase.

The User Experience lead collects user profile information during the Envisioning Phase. This person can be assigned
to other projects during this phase, if necessary. You may need to add additional team members to the User
Experience Role during the Developing, Stabilizing, and/or Deploying phases.

The Release Management lead helps to assess the current situation during the Envisioning Phase. This person can be
assigned to other projects during this phase. If necessary, add additional team members to the Release Management
Role during the Stabilizing and Deploying phases.

Any team members who work on other projects during the Envisioning Phase must demonstrate the capability to manage
their time and attention well, so as not to neglect their project responsibilities. Team members working on other projects
presents a risk, and it should be recorded and tracked as such.

If the Program Manager or other leads know in advance which people will be added to the team at a later stage, you can
note this in the project structure document. You may choose to make the project documentation available to them to read at
their discretion.

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 6/14
04/03/2018 Chapter 2 - Envisioning Phase

During the process of creating a solution, the team must be able to establish clear and natural relationships between their
respective occupation functions and responsibilities, and those defined by the structure of the MSF Team Model. Customers,
partners, and Microsoft consultants all may have their own development and operations approaches associated with an
organizational structure. The various approaches and structures must be reconciled in order to ensure that all parties
reference the same individuals within their companies and understand the roles they play during a project or in managing
operations. A taxonomy can facilitate the identification of these relationships.

The Microsoft Frameworks IT Occupation Taxonomy, available at

http://www.microsoft.com/technet/itsolutions/msf/default.mspx in the MSF resource library, is a helpful resource for
customers and partners, regardless of how they organize their business, to easily identify the individuals within the
organization who have the needed talents to successfully implement the solution. This is an important first step to ensuring a
smoothly run project.

When everyone involved in a project is using a common terminology to define roles and functions, the potential for
miscommunication is greatly reduced. Once the project is complete, the taxonomy can be applied to the operations
environment to ensure that the solution continues to achieve high performance.

Scaling Teams
Although MSF defines six distinct team roles, this does not mean that every team must be composed of exactly six people.
Depending on the nature and extent of the project, the core project team can be composed of more or fewer than six
people, some of whom may be working on the project part time.

Within a large organization, it often makes sense to dedicate some project members full time to their tasks in order to build
a robust and supportable solution. A dedicated team member is one who devotes 100 percent of his or her time to the
project and whose day-to-day responsibilities relate only to the project. This arrangement may not be practical within smaller
organizations. Smaller organizations may decide that team members who split their time between the project and other day-
to-day job functions can manage the scope of the project. The solution team needs to take these considerations into account
when planning and assembling for the project.

Assembling Small Teams

For small or resource-limited projects, consider assembling a small core team in which at least one of the members assumes
responsibilities for two or more roles. Some of the ways you can combine the roles for a project include:

Combining Release Management and User Experience.

Combining Test and User Experience.

Combining Program Management and Release Management.

For infrastructure migrations, combining Development and Release Management.

Some roles should not be combined. The Development Role should not be responsible for Test because this does not
provide an objective assessment of the development work. Likewise, one team member should not be responsible for
Program Management and Product Management. Though it may be tempting to assign these roles to the same person, the
roles may represent competing interests. For infrastructure projects, the Release Management Role may be sufficiently close
to the customer as to make it inappropriate to combine the role with that of Program Management.

For a very small project, you may have a core project team composed of only three people: one responsible for Program
Management and Release Management; one responsible for Development; and one responsible for Test, User Experience,
and Product Management. You may choose a different permutation depending on the nature of the project and the skills of
the team members, keeping the restrictions mentioned previously in mind.

Assembling Large Teams

For larger projects, you may want to assemble a team in which some roles are filled by more than one team member.

This will often be true of the Development Role, which can be divided into a number of different feature teams depending on
the nature of the project. You should create feature teams based on logical divisions of work. For example, in the migration
https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 7/14
04/03/2018 Chapter 2 - Envisioning Phase

of a large database-dependent application, one team might focus on migrating back-end stored procedures, while another
team focuses on migrating the user interface to the new development platform.

Each of these feature teams may consist of one or more developers, and each developer may work on one or more feature
teams. As you add more members to your team, be careful to ensure the team does not become too large to work together
effectively as a group.

You may choose to combine the small-team and large-team approaches, assigning multiple roles to a single team member
and several team members to a single role, provided they keep the goal of their assigned role on the solution team their top
priority.

Top of page
Defining the Project Structure
The project structure defines how the team manages and supports the project and describes the administrative structure for
the project team going into the subsequent project phases.

The main function of the project structure is to define standards the team will use during the project. These include
communication standards, documentation standards, and change control procedure standards.

Program Management takes the lead in defining the project structure.

Defining Project Communications

Program Management should use the project structure to define standards for team members to communicate with one
another. Among these standards can be a definition of the reporting structure under which team members operate,
procedures to elevate project issues, regular mandated status meetings, and any other project-specific communication
standards that need to be defined during the Envisioning Phase.

The document may also include e-mail names, aliases, telephone lists, mail addresses, server share names, directory
structures, and other information critical to team organization. Consider establishing a team collaboration environment
where communication can occur and progress be monitored and updated as necessary.

Defining Documentation Standards

The project structure can also define standards on how to create training materials and documentation related to the project,
including standards that prescribe the templates and applications the team should use to create documents.

Defining Change Control

The Program Manager must include change control standards in the definition of project structure. These standards can
apply to two distinct areas: the solution content and the project documents that describe the content, such as the functional
specification. For solution content, change control standards can include prescribed daily builds and the use of source
control and versioning software that controls access and solution components and provides the capability to roll back
changes as needed.

Change control also needs to be exercised over any changes that could affect the scope of the project. This control is
enforced by applying change control to project documents. This method of change control helps ensure that the team is
more capable of completing the project on time and within budget, and it prevents scope creep. Scope creep is defined as
the tendency to add features to the project in increments until the aggregate effect of the changes jeopardizes the projects
success.

Migration projects have an additional source of change that is not obvious but must be managed: the initial state of the
technology being migrated. This could be source code for applications or hardware/software configuration and versioning
for infrastructure. Although the initial state can be baselined when the migration project is started, operational needs may
require changes to that configuration while the migration is under way. These operational changes are typically subject to
configuration management standards imposed by an operations team.

The Program Manager and Release Manager should work with operations personnel responsible for the existing technology
to minimize and accommodate these changes. Long-lived migration projects may require a formal process to connect
operational configuration management to project change control.

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 8/14
04/03/2018 Chapter 2 - Envisioning Phase

Instituting change control early on helps the team baseline documentation early in the project and iterate through the
Envisioning and Planning Phases to complete the design. Controlling change throughout the process of stabilizing the
solution helps in the process of capturing metrics and controlling bugs and issues as the solution nears completion.

Interim Milestone: Core Team Organized

This milestone marks the point at which the key team members have been assigned to specific roles in the team and the
team has been organized. The specific responsibilities of each role are described in the project structure document.

The project structure document also clarifies the chain of accountability to the customer and designated point(s) of contact
that the project team has with the customer. These points of contact can vary depending on the circumstances of the project.

Top of page
Defining the Business Goals
Correctly identifying the business goals to be achieved is essential for project success. The MSF approach to achieving
business goals is to overcome problems that obstruct the path toward project success, or to take advantage of opportunities
to gain a competitive edge. A project team needs to clearly articulate the problems and opportunities and understand the
direction in which the business must move in order to reach its business goals.

The problem/opportunities statement for the project leads to the creation of a team vision for the project.

Business goals are longer term in perspective than are interim problems that must be resolved in order to achieve these
goals. The team needs to determine the best method for identifying the goals and agreeing on them.

You may look at a company's one year, three year, or five year business plan to identify elements that help define the goals
for this project. The purpose of defining business goals is to clearly articulate the objectives for this project while ensuring
that your solution supports those business requirements.

For migration projects, you should focus on the new or enhanced business goals to be achieved as a result of migrating the
existing application or infrastructure. It may be helpful to consider the goals satisfied by the existing application or
infrastructure as a way of identifying new or extended goals, but justification for the migration project should exceed the
justification for the initial work.

Top of page
Assessing the Current Situation
You must identify the gaps between the current and desired states of a business in order to create a solution that fulfills a
project teams business goals. Performing a gap analysis helps identify a path to the desired state of a business. Different
types of business and technology issues that you need to assess may include business policies, business operations, existing
systems, their load capacities, and other infrastructure components that will be affected by the solution.

Top of page
Creating the Vision and Defining Scope
Delineating the project vision and identifying the scope are distinct activities; both are required for a successful project.
Vision is an unbounded view of what a solution may be. Solution scope identifies the part(s) of the vision to be provided in a
version of the solution. Project scope refers to the work performed by the team to deliver the items in the solution scope.
Both solution scope and project scope must consider what can be accomplished within project constraints.

Creating the Project Vision

The vision statement establishes a long-term vision that addresses the problem statements and achieves the business goals.
Typically only a paragraph or two in length, the vision statement is not bound by the actual work the team expects to
perform as part of the current project, but should balance competing interests to provide a vision that can be shared among
team members and provide context for future decision making.

The team articulates this vision in a vision statement, which is one component of the vision/scope document. (See the MSF
Resource Library at http://www.microsoft.com/technet/itsolutions/msf/default.mspx for a template for the vision/scope
document.) The vision that guided the development of the existing implementation of an application or infrastructure
component should serve as a strong guide in developing the vision statement for a migration project.

Defining the Solution and Project Scopes

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 9/14
04/03/2018 Chapter 2 - Envisioning Phase

The solution scope places a boundary around the solution by defining 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. Solution 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.

Project scope defines what work will and will not be performed by the team in a project. The project scope applies the
constraints imposed on the project by resources, time, and other limiting factors to the overall solution vision expressed in
the vision statement.

MSF uses the trade-off triangle to help set scope. The trade-off triangle conceptualizes the idea that resources, schedule, and
features are three interconnected elements of any project, and that constraining or enhancing one or more of these elements
requires trade-offs. An element not defined in the triangle is quality; however, it is assumed to be a constant that is clearly
articulated in a quality bar by the project team at project inception.

For example, if the organization wants to incorporate a new set of features into the solution, the team will have to make a
trade-off somewhere, whether in the schedule, the resources, or other features.

Figure 2.3: The MSF trade-off triangle

A second tool, the trade-off matrix, can be used to set and manage scope by prioritizing the variables shown in the trade-off
triangle and by serving as an agreement between the team and customers. This agreement sets default priorities for trade-
off decisions. Fixed describes constraints that are essentially unchangeable. Chosen describes project constraints that are
identified as desired priorities. Adjustable describes project constraints that may be adjusted to accommodate the other two.

Figure 2.4: The MSF trade-off matrix

In the sample trade-off matrix shown in Figure 2.4, resources are considered fixed, the schedule is a desired priority, and
features will be cut if necessary in order to meet the schedule with the fixed amount of resources.

Because migrations involve replacing an existing system (whether application or infrastructure component), the fastest path
to success is frequently found through tightly restricting the scope of change to minimize the addition of features beyond
those delivered solely through the migration itself. When migrating an application to Windows, for example, testing
resources and time are minimized if no new application features are added during the migration itself. Even if the business
goals driving the migration include new feature requirements, you may find it best to add those new features in a separate
and subsequent project.

Top of page
https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 10/14
04/03/2018 Chapter 2 - Envisioning Phase

Defining High-level Requirements and User Profiles

In order to ensure that the project creates a business-driven solution, the team determines the needs of each key
stakeholder, sponsor, and end user. This information represents vital input for the solution concept, provides criteria for
evaluating the vision/scope document, and evolves to detailed requirements in the next phase.

Defining and Refining Requirements

This process begins with defining the high-level set of functional requirements and features that should be considered for
the project, focusing on business requirements. Once the set of potential requirements is defined, the project team narrows
the list to a number considered essential.

MSF advocates the use of versioned releases in defining project scope. Versioned releases help the project team respond to
ongoing changes in scope, schedule, and project risk. If time, budget, or resource constraints prevent deployment of the
entire vision at a given date, the team may decide to implement these in a later version.

In a migration, the first release might migrate core functionality. Subsequent releases would migrate additional functionality
or extend the migrated component to meet new customer needs. Versioned releases also provide the opportunity to make
changes in response to feedback from earlier releases. Versioned releases are especially important when the time to market
is highly critical. This type of scenario would involve trade-offs in features in favor of an early release of a stable solution that
greatly increases the business success. The team decides on features that would be nice to include, but that will be omitted
for the initial release.

Defining User Profiles

The purpose of user profiles is to describe the solutions users and their relationship to the solution. The User Experience and
Product Management roles, as advocates for the end user and the customer, respectively, need to work together to predict
user behavior. The prediction is achieved by identifying users needs and requirements with respect to the solution; or, in
other words, what they are doing that the solution will facilitate.

An effective way to do this is to create profiles that include these activities for different categories of users, usually grouped
by their functional areas. Users are often from both the IT and business areas of the customer's organization. Business users
might include accounting, procurement, and warehouse operations. IT users could include help desk operations and
database administration.

All members of the team need to have an accurate understanding of the users and their needs. User profiles enable the team
to assess user expectations and take these into account when determining project risks, goals, and constraints.
Understanding user profiles and identifying what these users want to do when using the solution is critical to the success of
developing and maintaining the right solution and realizing business value.

Defining Usage Scenarios

The User Experience Role further refines the requirements for the solution by developing usage scenarios. 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 occur within the users' environment. These events should be described by their
objectives, key activities, the sequences of those activities, and the expected results. This work often continues into the
Planning Phase.

Top of page
Developing the Solution Concept
The solution concept outlines the approach the team takes to meet the goals of the project and provides the basis for
moving into the Planning Phase. Once the team has identified the business problem and defined the vision and scope, it
creates the solution concept. The purpose of the solution concept is to provide 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.

When developing the solution concept, it can be helpful to concentrate less on specific technologies and more on the ways
the technology can deliver the business value requirements. Important criteria to consider when determining whether a
solution concept meets a teams needs include:

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 11/14
04/03/2018 Chapter 2 - Envisioning Phase

Project success factors

Operational concept

Acceptance criteria

Interim Milestone: Vision/Scope Document Drafted

At this interim milestone, the first draft of the vision/scope document has been completed and is circulated among the team,
customer, and stakeholders for review. During the review cycle, the document undergoes iterations of feedback, discussion,
and change. This document records much of the information and decisions made by the project team to this point: a
statement of the business opportunity, a description of the solution concept, and a statement of the solution design
strategies.

Top of page
Assessing Risk
MSF stresses assessing project risk continuously throughout a project and makes this the responsibility of every team
member. Risk is defined as the possibility of suffering a loss or, more specifically, the possibility of a negative outcome that is
assumed in order to pursue an opportunity for gain in the project. Risk is a part of every solution implementation project.
Risk management involves anticipating, addressing, mitigating, and preventing risks. Prioritizing risks enables the team to
address high-risk items early. The following section describes how a team quantifies top risks in a project in order to
prioritize them.

Doing the Initial Risk Assessment

During the Envisioning Phase, the team creates a risk assessment document, assembling all the known risks and assessing
each one for probability (the chance the negative outcome will occur) and impact (the amount of loss that will result if the
negative outcome occurs). The Program Manager takes the lead when creating the risk assessment document.

The team may want to compare the risks associated with different solution concepts to help select one. This can be done by
using numeric scales to assess risk probability and impact. Then, calculate each risks exposure by multiplying the two
numbers together, such that probability ??impact = exposure. The exposure represents the overall threat of the risk, which
may not be readily apparent. A risk with a high probability but low impact could have exactly the same exposure as another
risk that has a low probability and high impact. Comparing risks on the basis of their exposure values allows the team to
address the most severe risks first. One common way of articulating risk impact is in terms of the probable financial loss if the
negative outcome that the risk describes does in fact take place.

Once the team has created the risk assessment document and ranked each risk by exposure, the team can focus on the
highest-priority risks, often called a top 10 list, though the number can vary. The Program Manager should review this list
frequently, adding and removing risks as they move up and down in importance.

Some risks are common to any migration project. These include:

Lack of necessary skill sets to complete the project.

Scope creep results in a migration project that requires so much time to complete that the basis for the migration, the
target, or both, change too much.

The migrated application fails to meet one or more functional requirements.

The migrated infrastructure component fails to scale to the required degree.

Learning More about Risk Assessment

Performing proper risk assessment requires an understanding of the philosophies underlying risk management in general
and the MSF Risk Management Discipline in particular. Both a detailed white paper to help you acquire this knowledge and
risk management tools that facilitate the creation of the risk assessment document are available at
http://www.microsoft.com/technet/itsolutions/msf/default.mspx in the MSF resource library.

Top of page

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 12/14
04/03/2018 Chapter 2 - Envisioning Phase

Closing the Envisioning Phase

Closing the Envisioning Phase requires completing a milestone approval process. The team needs to document the results of
the different tasks it has performed in this phase, to enable the project team, customer, and key project stakeholders to
commit to the vision and scope of the project.

Key Deliverables from the Envisioning Phase

The following is a checklist for the deliverables and their contents that the team creates during the Envisioning Phase:

Vision/scope document

Problem statements and business objectives

A review of the existing processes

High-level requirements

User profiles identifying who will benefit from the solution

A vision statement and scope definition

The solution concept outlining the approach the team will take to plan the project

Solution design strategies

Project structure document

A description and mapping of all MSF team roles

A project structure and process standards for the team to follow

Risk assessment document

A preliminary risk assessment

List of the top identified risks

Milestone review report

Team member project progress report

Team lead project progress report

Top of page
Key Milestone: Vision/Scope Approved
Reaching the Vision/Scope Approved Milestone concludes the Envisioning Phase. At this point, the project team and the
customer have agreed on the overall direction for the project, including which features the solution will and will not include
and a general timetable for delivery.

Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives
of each team role and any important customer representatives who are not on the project team, signal their approval of the
milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a
project deliverable and is archived for future reference.

Top of page
Download

Get the UNIX Migration Project Guide

Update Notifications
https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 13/14
04/03/2018 Chapter 2 - Envisioning Phase

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Top of page

© 2018 Microsoft

https://technet.microsoft.com/en-us/library/bb497039(d=printer).aspx 14/14