Chapter 2 - Envisioning Phase
On This Page
.gif){kind=icon}
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
.gif)
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 Management Program Management |
Defining the project structure |
Program Management |
Defining the business goals |
Product Management |
Assessing the current situation |
Program Management |
Creating the vision and defining the scope for the project |
Product Management |
Defining high-level requirements and user profiles |
Product Management |
Developing the solution concept |
Program Management |
Assessing risk |
Program Management |
Closing the Envisioning Phase |
Project team |
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.
.gif)
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 Marketing Customer advocacy Product planning |
Act as customer advocate Drive shared project vision/scope Manage customer requirements definition 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 constraints |
Project management Solution architecture Process assurance Administrative services |
Drive development process to ship product on time Manage product specification primary project architect Facilitate communication and negotiation within the team 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 Implementation architecture and design Application development Infrastructure development |
Specify the features of physical design Estimate time and effort to complete each feature Build or supervise building of features Prepare product for deployment Provide technology subject matter expertise to the team |
Test: approve for release only after all product quality issues are identified and addressed |
Test Planning Test engineering Test reporting |
Ensure all issues are known Develop testing strategy and plans Conduct testing |
User Experience: enhance user effectiveness |
Accessibility Internationalization User advocacy Training/support material Usability research and testing User interface design |
Act as user advocate on team Manage user requirements definition Design and develop performance support systems Drive usability and user performance enhancement trade-off decisions Provide specifications for help features and files Develop and provide user training |
Release Management: achieve smooth deployment and ongoing operations |
Infrastructure Support Operations Logistics Commercial release management |
Act as advocate for operations, support, and delivery channels Manage procurement Manage product deployment Drive manageability and supportability trade-off decisions Manage operations, support, and delivery channel relationship 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. 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.
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 https://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 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.
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.
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.
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.
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.
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 https://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
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.
.gif)
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.
.gif)
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.
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.
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:
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.
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 https://www.microsoft.com/technet/itsolutions/msf/default.mspx in the MSF resource library.
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
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.
Download
Get the UNIX Migration Project Guide
Update Notifications
Sign up to learn about updates and new releases
Feedback