Chapter 1 - Introduction to the Microsoft Solutions Framework

Article
12/05/2007

Introduction and Goals

For large-scale projects, such as database migrations, it is vital to have a cohesive and structured project framework in place. This foundation ensures that projects are carefully planned, roles and tasks are clearly identified and defined, and that the thousands of crucial details are addressed for a successful migration.

In this chapter, you will learn about Microsoft Solutions Framework (MSF), which has been used successfully on numerous IT projects. This adaptable and robust project framework provides a comprehensive structure that assists in guiding the project from the initial planning stages until after the project has been completed. If you are familiar with MSF, skip this chapter and continue with Chapter 2, "Envisioning Phase."

Overview of MSF

Every successful project follows a methodology to achieve its objectives. The methodology employed in this migration guide is the Microsoft Solutions Framework. A vast amount of information about MSF is available from Microsoft, and the UNIX Migration Project Guide provides a thorough explanation of MSF for specific audiences of this migration guide, such as the team members that fulfill the Program Management role. Yet not every team member on your migration project needs in-depth knowledge of MSF to successfully perform their team function. Because this is the case, the following brief overview is intended to provide all team members with a high-level overview of MSF that will familiarize them with basic concepts and terminology and help them to better understand the specific sections of this migration guide that they will need to read, understand, and execute.

MSF was created to maximize the success of IT projects throughout the entire IT life cycle. This information is derived from the experience gained within Microsoft on large-scale software development and service operation projects, the experience of Microsoft’s consultants, and common best practices from the worldwide IT industry.

As opposed to a prescriptive methodology, MSF provides a flexible and scalable framework to meet the needs of any sized organization or project team. MSF guidance consists of principles, models, and disciplines for managing the people, process, and technology elements that most projects encounter. A detailed introduction to the MSF models and disciplines is available at https://www.microsoft.com/msf.

MSF Foundational Principles

At the core of MSF are eight foundational principles. For detailed information on the eight foundational principles, download the MSF Version 3 Overview from https://msdn.microsoft.com/vstudio/enterprise/msf/.

The eight foundational principles of MSF are:

Foster open communications. The MSF Process Model enables an open and free flow of information among the team members and key stakeholders to prevent misunderstandings and reduce the probability that work will have to be redone. Documenting the progress of the project and making it available to the team members, stakeholders, and customers can best achieve this.
Work toward a shared vision. The MSF Process Model provides a phase (the Envisioning Phase) and a separate milestone (Vision/Scope Approved) for creating a shared vision. A vision includes detailed understanding of the goals and objectives that the solution needs to achieve. A shared vision highlights the assumptions that the team members and customers have for the solution.
Empower team members. Empowering the team members implies that the members accept responsibility and ownership of work assigned to them. Team empowerment can be achieved by preparing schedules where the team members commit to complete their work on a fixed date. This makes the team members feel accountable and also provides a method for identifying any potential delays early in the project.
Establish clear accountability and shared responsibility. The MSF Team Model is based on the principle that each role is accountable for the quality of the solution. All the team members share the overall responsibility of the project because the project can fail due to a mistake made by a single member.
Focus on delivering business value. The solution must deliver value to the organization in the form of business value. This business value is achieved only after the solution is completely deployed into the production environment.
Stay agile, expect change. MSF assumes that the solution will encounter continuous changes before being deployed to the production environment. The team should be aware and prepared to manage such changes.
Invest in quality. In MSF, each team member is responsible for the quality of the solution. To confirm the quality throughout the project's duration, a test team is formed. This ensures that the solution meets the quality level of the stakeholders.
Learn from all experiences. MSF states that the experiences derived from one project should be used and shared with teams in other projects. These experiences can also help to identify the best practices that should be followed in your organization.

The MSF Team Model — Overview

The MSF Team Model was developed over a period of several years to compensate for some of the disadvantages imposed by the top-down, hierarchical structure of traditional project teams. Teams organized under the MSF Team Model are small and multidisciplinary teams of peers, although the model is scalable for both small and large projects. Team members share responsibilities and balance each other’s competencies to keenly focus on the project at hand. They are expected to share a common project vision, a focus on deploying the project, high standards for quality and communication, and a willingness to learn. Figure 1.1 shows the role clusters of the MSF Team Model.

Figure 1.1 The MSF Team Model

The MSF Team Model emphasizes the importance of aligning role clusters (commonly referred to simply as "roles") to business needs. It does this by organizing each role around a quality goal that the project must meet to be successful. Each role aggregates a "cluster" of related functional areas and responsibilities. The functional areas each require a different discipline and focus, but are related in that they contribute toward meeting the quality goal.

The result is a well-balanced team whose skills and perspective represent all of the fundamental project goals. For team members, possessing a clearly defined role and owning a clearly defined goal is motivational. It increases the understanding of responsibilities, and ultimately leads to a better solution. Because each goal is critical to the success of a project, the roles that represent these goals are considered to be equally important. Persons filling the roles are given equal say in critical decisions and are thought of as peers. MSF teams are known as "teams of peers." Table 1.1 associates each role cluster with a quality goal.

Table 1.1: Role Clusters and Quality Goals

Role Cluster	Goal
Program Management	Deliver the solution within project constraints
Development	Build to specification
Test	Approve for release only after all product quality issues are identified and addressed
User Experience	Enhance user effectiveness
Release Management	Achieve smooth deployment and ongoing operations
Product Management	Satisfy customers

The MSF Process Model — Overview

The MSF Process Model describes a high-level sequence of activities for building and deploying IT solutions. Rather than prescribing a specific series of procedures, it is flexible enough to accommodate a broad range of IT projects. MSF combines two industry standard models: the waterfall model, which emphasizes the achievement of milestones, and the spiral model, which focuses on the continual need to refine the requirements and estimates for a project. An innovative aspect of the MSF process model is that it covers the life cycle of a solution from project inception to live deployment. This helps project teams focus on customer business value, because no value is realized until the solution is deployed and in operation.

Figure 1.2 The MSF Process Model showing phases and major milestones

MSF is a milestone-driven process. Milestones fall at the end of each phase and contain criteria for completing the phase. Important deliverables must have been completed and critical questions, such as: Does the team agree on the project scope? Have we planned enough to proceed? Have we built what we said we would build? Is the solution working properly for the customer? must be satisfactorily answered. The project team and key stakeholders review the deliverables and reach agreement that the project can proceed to the next phase in a milestone meeting.

MSF is also an iterative process. The process model is designed to accommodate changing project requirements by iterating through short development cycles and incremental versions of the solution.

The iterative aspect of the MSF process applies well to migration projects, which are frequently driven by an iterative process. In some cases, the migration task itself is approached iteratively. The first cycle migrates limited, basic functionality to the new platform; and subsequent cycles add additional capabilities to the new environment until it is equivalent to the original, unmigrated technology. In some other migration projects, the first cycle completely migrates some technology to a new environment, while subsequent cycles extend the technology beyond its original capabilities. Iterative approaches to migration projects provide a means to control project risk and create greater flexibility to accommodate changing requirements.

The MSF Process Model originated with the process used by Microsoft to develop applications. This model may be applied to traditional application development environments, but is equally appropriate for the development and deployment of enterprise infrastructure solutions, Web development, e-commerce, and distributed applications.

Although the Program Management Role orchestrates the overall process within each phase, the successful achievement of each milestone requires special leadership and accountability from each of the other team roles. As a project moves sequentially through each phase, the level of effort for each of the roles varies. The use of milestones helps to manage this ebb and flow of involvement in the project.

Table 1.2: Major Milestones and Primary Drivers

Milestone	Primary Driver(s)
Vision/Scope Approved	Product Management
Project Plans Approved	Program Management
Scope Complete	Development and User Experience
Release Readiness Approved	Test and Release Management
Deployment Complete	Release Management

Each phase also has interim milestones that lead to the achievement of the final phase milestone. Recommended interim milestones are shown in Figure 1.3, but they may need to be modified for a particular project.

Figure 1.3 MSF Process Model with interim milestones

The MSF Disciplines — Overview

MSF makes use of three classic disciplines, Risk Management, Readiness Management, and Project Management, which it has adapted to fit the framework. They are reflected in both the Process Model and the role responsibilities defined in the Team Model. This section describes each discipline briefly. For a thorough discussion of each discipline and its application within MSF, see the respective white papers available at https://msdn.microsoft.com/vstudio/enterprise/msf/.

Risk Management

The MSF Risk Management Discipline advocates proactive risk management, continuous risk assessment, and integration into decision-making throughout the project and operational life cycle. Risks are continuously assessed, monitored, and actively managed until they are either resolved or the possible negative event happens and the risks have become real problems to be handled as such. The MSF risk management process defines six logical steps the team uses to manage current risks, plan and execute risk management strategies, and capture knowledge for the enterprise. Figure 1.4 illustrates the relationship between the six steps.

Figure 1.4 The MSF risk management process

The following list provides detailed information about each of the six risk management steps.

Identify. The process of risk identification calls for all team members to participate in surfacing risks to make the team aware of potential problems. As the input to the risk management process, risk identification should be undertaken as early as possible and repeated frequently throughout the project life cycle.
Analyze and Prioritize. Risk analysis transforms the estimates or data about specific project risks that surface during risk identification into a form that the team can use to make decisions regarding prioritization. Risk prioritization enables the team to commit project resources to manage the most important risks.
Plan and Schedule. Risk planning takes the information obtained from risk analysis and prioritization and uses it to formulate strategies, plans, and actions. Risk scheduling ensures that these plans are approved and then incorporated into the project management process and infrastructure to ensure that risk management is carried out as part of the day-to-day activities of the team. Risk scheduling explicitly connects risk planning with project planning.
Track and Report. Risk tracking monitors the status of specific risks and the progress in their respective action plans. Risk tracking also includes monitoring the probability, impact, exposure, and other measures of risk for changes that could alter priority, risk plans, and project features, resources, or schedule. Risk tracking enables visibility of the risk management process within the project from the perspective of risk levels as opposed to the task completion perspective of the standard operational project management process. Risk reporting ensures that the team, sponsor, and other stakeholders are aware of the status of project risks and the plans to manage them.
Control. Risk control is the process of executing risk action plans and their associated status reporting. Risk control also includes initiation of project change control requests when changes in risk status or risk plans could result in changes in project features, resources, or schedule.
Learn. Risk learning formalizes the lessons learned from the project, collects the relevant project artifacts and tools, and captures that knowledge in reusable form.

Readiness Management

The MSF Readiness Management Discipline defines readiness as a measurement of the current state versus the desired state of knowledge, skills, and abilities (KSAs) of individuals in an organization. This measurement is the real or perceived capabilities of the individuals at any point during the ongoing process of planning, building, and managing solutions.

Each role on a project team includes key functional areas that the individuals undertaking those roles must be capable of fulfilling. Individual readiness is the measurement of the state of an individual with regard to the KSAs needed to meet the responsibilities required of their particular role. The MSF Readiness Management Discipline includes a process to help teams prepare for the KSAs needed to build and manage projects and solutions.

The most basic approach to the readiness process is simply to assess skills and make appropriate changes through training. On projects that are small or have short timeframes, this streamlined approach is quite effective. For longer term or serial projects, organizations can benefit from performing the steps of defining the skills needed, evaluating the results of change produced by training, and keeping track of KSAs. This allows for the full realization of readiness management, and is typically where organizations reap the rewards of investments in readiness activities.

The readiness management process is composed of four steps: Define, Assess, Change, and Evaluate. Each process step includes a series of tasks to help reach the next step.

Figure 1.5 The readiness management process

Define

This step focuses on defining requirements. It identifies and describes the scenarios, competencies, and proficiency levels needed to successfully plan, build, and manage the solutions. It also determines which roles in the team should be proficient in the defined competencies. Depending on the role, the individual filling it may need to be proficient in one or many of the defined competencies.

Scenarios describe the different types of activities that occur in a typical enterprise. Scenarios generally fall into one of four categories defined in terms of the business value they offer the organization — High Potential, Strategic, Key Operational, and Support. Different scenarios call for different types of skills and knowledge and distinct approaches to obtaining the appropriate resources and skills for that project type.

High Potential. These focus on the situations an IT department encounters when planning and designing to deploy, upgrade, or implement a new product, technology, or service in its organization. These are typically research type situations in which the technology is brand new or in beta form. The organization needs to have a high degree of agility and the capability to investigate and evaluate new technologies. For these scenarios, it needs to be prepared to obtain (for a short period) the best expertise available.
Strategic. Scenarios in this category focus on the situations an IT department is likely to encounter when exploiting new technologies, products, or services. These are typically market-leading solutions that could lead to business transformation defining the to-be long-term architecture. Here the organization needs in-house, in-depth expertise at the solution architect level and the capability of bridging skills across technology to the business.
Key Operational. Scenarios in this category focus on the situations an IT department is likely to encounter once it has deployed, upgraded, or implemented a new product, technology, or service that has to coexist, or continue to seamlessly interact with legacy software and systems. These are typically today's business-critical systems, aligned with the as-is technology architecture. Quality of technical knowledge and process are critical, as is ready availability of the skills applicable to the relevant technologies. The challenges are easier to plan for when the technologies are proven. Typically, organizations obtain the readiness and skills needed in this scenario by out-sourcing or by developing strong in-house capability.
Support. Scenarios in this category focus on situations in which it is necessary to extend the product to fit the needs of a customer’s environment. These are typically valuable but not business-critical solutions and often involve legacy technology. Here, cost of delivery becomes paramount and the organization may decide to rely on external skills (particularly for legacy) on a reactive basis.

When determining the most appropriate scenario for a migration project, keep in mind that the technology being migrated was initially deployed under one scenario. For example, it might have been implemented when the technology was new, or it might have been a key operational technology. As the new migrated environment is envisioned, though, a different scenario may apply. If the technology has matured, for example, what was a “high potential” project may be treated, in migration, as a “key operational” scenario. Alternatively, what might have originally been a classical support-scenario project might involve, as a result of migration to newer technology, something more akin to the high potential scenario. Identifying the most appropriate scenario helps to map the appropriate competencies and proficiencies required for the migration.

Competencies describe the measurable objectives, or tasks, in a given scenario that an individual needs to be able to complete with proficiency. A single competency is used to define a major part of an individual’s job or job responsibility relating to performance. A competency can be considered a combination of skills, knowledge, and performance requirements
Proficiencies are the measure of the capability to execute tasks associated with a particular competency within a given scenario. An individual's proficiency level provides a baseline for analyzing the gap between that individual's current skill set and the necessary skills for completion of the tasks associated with the given scenario.

Assess

The assess step focuses on the individual team members. It determines the competencies that these individuals currently possess. It is during this step that analysis of the competencies as they relate to the various job roles is undertaken to determine the skills of individuals within each of these roles. The desired competencies are then analyzed against the current competencies — the “to-be" versus the “as-is.” This work enables the development of learning plans, so that desired competency levels can be reached. The following tasks need to be performed to complete the assess step:

Measure individuals' knowledge, skills, and abilities through self-assessments or skills assessments (tests).
Analyze gaps by comparing the individual's KSA measurements to the expected proficiency level for the role. Individuals can then concentrate on bridging these gaps through the use of learning plans.
Create learning plans that identify the appropriate resources and methods (such as training materials, courseware, white papers, computer based training, mentoring, on-the-job, and self-directed training) to fill the gaps. Learning plans should consist of both formal and informal learning activities, and guide individuals through the process of moving from one proficiency level to the next.

Change

In this step, individuals advance their skills through learning in order to bridge the gap between their current proficiency and desired proficiency levels. In this step, the following tasks are accomplished:

Train individuals using the actual training, hands-on learning, and mentoring techniques described in the learning plans.
Track the learning of each individual. Monitor and report the progress of individuals and their skills by scenario and competency. Tracking progress enables individual and overall readiness to be determined at any time in the life cycle.

Evaluate

This step determines whether the learning plans were effective and whether the lessons learned were successfully implemented on the job. At this point it is time to:

Review results to see if more training is necessary or if what was learned is being implemented on the job.
Manage knowledge to foster the sharing of the new intellectual resources. This sharing of knowledge enhances the collective knowledge of the solution team and the enterprise and fosters a learning community. Additionally, a formal knowledge management system can provide a way to share common and repeatable best practices that help reduce costs and risks for other project teams.

The MSF Readiness Management Discipline is considered an ongoing, iterative approach to readiness. Following the steps in the process helps manage the various tasks required to align individual, project team, or organizational KSAs. It can lead to better individual, project team, and strategic planning success.

Project Management

The third important discipline adopted by MSF is the Project Management Discipline. To deliver a solution within project constraints, strong project management skills are essential. The MSF Team Model does not contain a role known as Project Manager; however, most project management functions are conducted by the MSF Program Management Role.

Project management is a set of skills and techniques that include:

Integrating planning done for each aspect of the project.
Conducting change control.
Defining and managing the scope of the project.
Preparing a budget and managing costs.
Preparing and tracking schedules.
Getting the right resources allocated to the project.
Managing contracts and vendors, and procuring project resources.
Facilitating team and external communications.
Facilitating the risk management process.
Documenting and tracking the team’s quality management process.

Three distinctive characteristics of the MSF approach to project management stand out:

Most of the responsibilities of the role commonly known as "Project Manager" are encompassed in the MSF Program Management Role Cluster. As the size and complexity of a project grows, this role cluster is broken out into two branches of specialization: one dealing with architecture and specifications and the other dealing with project management.
In larger projects requiring scaled-up MSF teams, project management activities occur at multiple levels. As the teams grow in number, the project management activities become distributed among the team leads for each of the MSF team roles. The Program Management Role is then responsible for management of the “rolled up” work from the leads in order to manage the entire solution.
Some large or complex projects require a specialist Project Manager or project management team. As the size, complexity, or risk becomes very large, often specialist roles or teams are created to focus on one particular area. For the Program Management Role, this can be done to break the many project management tasks into smaller, more manageable responsibility areas. These could include a specialist project manager, risk manager, solution architect, schedule administrator, and so on.

The differentiating factor of the MSF approach to project management is that the project management job function and activities do not impose a hierarchical structure on the decision-making process. MSF advocates against a rigid, “dictator” project management style because it works against an effective team of peers.

The team of peers approach is a key success factor of MSF. All roles in MSF are considered equally important and major decisions are arrived at by consensus of the core team. If that consensus cannot be achieved, the Program Management Role plays a tiebreaker function, making the final decision on the issue by transitioning into a decision leader to drive the project forward. This decision is made from the perspective of meeting the customer’s requirements and delivering the solution within the constraints. Afterward, the team immediately resumes their normal peer relationships.

Overview of MSF Phases

The information in this section describes the MSF phases that structure the organization of this migration guide. These phases create the structure used for the project throughout the rest of this guide.

Envisioning Phase

In the Envisioning Phase, the team identifies the vision and scope of the project by preparing a vision and scope document.

During this phase, goals for the project are formed and a vision statement is created that defines the entire project. This shared vision helps the team to work towards a common objective. The project team is assembled and the team members are empowered by having roles and responsibilities assigned to them.

Another important activity in this phase is the identification of risks and preparation of mitigation and contingency plans. The risks identified and the mitigation plans are used throughout the life cycle of the project. Refer to Chapter 2, "Envisioning Phase," for more details on the tasks and deliverables of the Envisioning Phase.

Planning Phase

During this phase, the existing environment is assessed to form a solution design. The main activity of this phase is to do a detailed planning to ensure success of the project. In this phase, a master project plan deliverable is created that consists of all sub-plans, such as the test plan, and development plan.

The plan focuses on budgets, quality, schedule, and the technical implementation of the solution. The project team follows these plans in the subsequent phases. Refer to Chapter 3, "Planning Phase," for more details on the tasks and deliverables of the Planning Phase.

Developing Phase

During this phase, the application components undergo transformation based on the development plans.

Components that need a rewrite are developed. In components that are ported, changes based on syntax compliancy, performance, and security are carried out. The source code and executables help to create the deliverables of this stage. Refer to Chapter 4, "Developing: Databases — Introduction," for more information on how to migrate a database. Chapter 10, "Developing: Applications — Introduction," provides different scenarios for migrating an application.

Stabilizing Phase

During this phase, all the components are tested collectively to ensure that the entire solution operates properly.

The testing criteria include achieving the desired functionality, security, and performance requirements. To ensure this, both white box and black box testing are performed. The tested database and components form the deliverables of this stage.

Once testing is complete, the solution must be stabilized to ensure that it meets defined quality levels. If the migration is complex, a pilot test of the application can also be performed during the Stabilizing Phase. Refer to Chapter 18, "Stabilizing Phase," for more details on the tasks and deliverables of the Stabilizing Phase.

Deploying Phase

In this phase, the team deploys the solution and ensures that it is stable and can be used. The tested solution is moved into production and transferred to operations.

During this phase, the solution components are tuned in the production environment. A solution signoff is obtained from all stakeholders that confirms that the application meets the requirements developed during the Envisioning and Planning Phases. Refer to Chapter 19, "Deploying Phase," for more details on the tasks and deliverables of the Deploying Phase. The migration project and the guidance are deeply rooted in the MSF methodology, and the chapters are in chronological order of the MSF phases starting from Chapter 2, "Envisioning Phase, through Chapter 19, "Deploying Phase."