UNIX Migration Project Guide

Chapter 1 - Introduction

Overview

The UNIX Migration Project Guide (UMPG) offers "how to" project guidance from Microsoft that supplements the specific technical guidance provided in UNIX migration solution guides. These guides are two major components of Solution Accelerators, which are intended to help customers plan, build, and deploy solutions to business problems. Solution Accelerators are lab tested and customer proven, cross-product technical guidance from Microsoft.

Whereas the technologies involved in migrating an application, database, or infrastructure from UNIX to the Microsoft Windows environment differ for each solution, best practices for organizing people and processes to successfully complete IT projects are remarkably consistent across a variety of projects. It is well accepted that following best practices can make the difference between success and failure in a project, yet incorporating them into each solution guide along with technical material can result in needless repetition and overly long guides. The UMPG makes the practices available by concentrating them in one guide that readers can apply to all UNIX migration projects. The solution guides are thus focused more narrowly on the technical content that is germane to the solution.

Who Should Read This Guide

The UMPG is addressed to IT professionals who are tasked with the project of migrating applications, databases, or infrastructures from UNIX to the Microsoft Windows environment. Its audience may include consultants who are helping an organization with a migration project as well as individuals within the organization who are participating in the project. Persons with job titles such as network administrator and developer might be given the responsibility for a migration project.

Most projects require a team of people, each of whom contributes a different kind of expertise to the project. Regardless of organizational job title, the team member who is given the responsibility for managing the project should read the entire guide. On the other hand, individuals whose project responsibilities are limited to specific areas, such as testing or development, may wish to read just the "Introduction" and sections in the guide that pertain to their focus.

How to Use This Guide

The UMPG is designed to be used in conjunction with specific solution guides that provide detailed technical information specific to each solution. The organization of the UMPG follows the Microsoft Solutions Framework (MSF) process model for IT projects, beginning with the project phase of Envisioning, proceeding through the Planning, Developing, Stabilizing phases, and ending with Deploying. A similar organizational structure in the solution guides is intended to make it easy to use the guides together.

Considered from the broader perspective of the entire information technology (IT) life cycle stages (plan, build, deploy, and operate), the MSF process for IT projects addresses only the first three stages. The parts of the book provide the IT life cycle context for the benefit of readers who are familiar with these stages (Part 1: Plan, Part 2: Build, Part 3: Deploy). Operate, the final life cycle stage, which logically follows the completion of a project, is concerned with ongoing processes. The Microsoft Operations Framework (MOF) provides general guidance related to operations and is described briefly in the appendix. More detailed information on MOF is available at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx.

Table 1.1 associates the MSF phases to the IT life cycle stages and defines the high-level activities within each phase.

Table 1.1 IT Life Cycle Stages and MSF Phases

IT Life Cycle Stage	MSF Process Model Phase	Focus
Plan	Envisioning	The team defines the vision and the scope of the project based on the business need, organizes the project, and delivers an approved vision/scope document.
	Planning	The team develops the conceptual, logical, and physical designs and creates the functional specification. It also develops project plans addressing development, testing, communication, and other tasks, and creates and delivers the master project schedule.
Build	Developing	The team builds and tests the solution components.
	Stabilizing	The team completes testing the solution and performs pilots and reviews.
Deploy	Deploying	The team deploys the solution and ensures that it is stable and usable. Responsibility then shifts to operations and support teams.

Each chapter of the UMPG is devoted to one phase and provides information about the specific processes, the roles involved during the phase, and deliverables that are created as a result of implementing the phase. Templates for specific milestone deliverables are available in the MSF Resource Library at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx. Additionally, the guide refers to other sources of information that may be useful.

The UMPG also offers high-level information about the MSF principles and models underlying the recommended approach. The guide is designed with the assumption that, if you are using MSF, key members of your project team, at a minimum, have had MSF training. To supplement that training with additional references, the MSF white papers are available at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

If your organization uses another project methodology or framework, the process and team models presented here can be mapped to it in order to enable you to apply the guidance. It is recommended to make sure that at least the issues that the process and team models address in this guide are addressed in your project.

Individual solution guides present technical information within the context of the project phases where it is applicable. To that extent, they follow the sequence of this guide and deliver their guidance in terms of the MSF process and team models documented here. Again, if your process and team models differ, you may need to translate between them and the models presented in this guide to apply the guidance within your own project.

Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF)

The Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF) were created to maximize the success of IT projects and operations throughout the entire IT life cycle. They provide guidance and proven practices organized into two complementary and well-integrated bodies of knowledge for effectively planning, building, deploying, and operating solutions. This information is derived from the experience gained within Microsoft on large-scale software development and service operation projects, the experience of Microsofts 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 size organization or project team. MSF guidance consists of principles, models, and disciplines for managing the people, process, and technology elements that most projects encounter. An introduction to the MSF models and disciplines is available within the Microsoft Solutions Framework Basics section of this document, and more details can be found at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

Top of page

Microsoft Solutions Framework Basics

This section introduces the MSF Team Model, MSF Process Model, and three disciplines that are important to the functioning of MSF.

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 others 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
See full-sized image.

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.2 associates each role cluster with a quality goal.

Table 1.2 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. It 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 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
See full-sized image.

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, distributed applications, and other multifaceted initiatives that may appear in the future.

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.3 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
See full-sized image.

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 in the MSF Resource Library at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

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
See full-sized image.

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
See full-sized image.

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 projects 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, and/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, and/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 customers 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 individuals 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 benchmark, or starting point, 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. Monitoring 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 in order to make necessary adjustments.

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. In order 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 teams 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, often this is 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 in order to drive the project forward. This decision is made from the perspective of meeting the customers requirements and delivering the solution within the constraints. Afterward, the team immediately resumes their normal peer relationships.