The MSF Development Team Model | Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit

Because a large number of activities must be performed and several perspectives must be addressed in each project, assigning ownership of key project-success factors to specific team roles significantly improves project-success rates. As shown in Figure 3.1, MSF identifies six distinct roles that comprise the MSF Development Team Model. Each role has clearly defined responsibilities, and when all roles are combined at the completion of a project, all critical success factors will have been covered.

click to view at full size

Figure 3.1 MSF Development Team Model's roles

Usually, each role has a team of people assigned to it to carry out that role's responsibilities, with one person acting as the role team's leader. Assigning a leader to each role creates a single point of contact to represent that role on the project team.

CAUTION
Assigning responsibility to teams of people can mean that no one takes responsibility for anything. But with MSF, each team role has specific responsibilities for critical portions of the development process. The overall success of the project is the primary shared responsibility of all the team members.

For project teams to be successful, they should have:

Experienced leaders.

Self-motivated team members, empowered to make decisions and accountable for the success of their team's role.

A focus on shipping the product.

A commitment to a shared project vision.

To facilitate communication, a project team should be a small, multi-disciplined group that has the following characteristics of good teambuilding:

Trust People can rely on each other, and each person exhibits repeatable patterns of consistent behavior. "We do what we say we will do."

Respect People have regard for each other's abilities. "We all add value to the team."

Commitment Everyone agrees on the project's goals and accepts success as an all-or-nothing proposition. "We will get it done, period."

Accountability People act on clearly defined goals, responsibilities, and expectations. "I'll do this, you'll do that, and by Tuesday we'll have built our house."

These fundamental characteristics will lead the team to what's known as the "right" principle: "It's everyone's responsibility to ship the right product at the right time."

Product Management

The job of the Product Management role is to respond to the customer's need or problem. The key contribution of this role is to drive the team to a shared vision of how to meet the need or solve the problem. Product Management answers the business-driven question "Why are we doing this?" and ensures that all members of the team know and understand the answer.

The key external goal of this role is customer satisfaction. Product Management can achieve this goal by acting as the customer advocate to the team and as the team advocate to the customer. (Here, it's important to distinguish between the customer and the users: The customer pays for the product, while the users use it.) Product Management works with Program Management to determine the "tradeoffs" between what the project will deliver, the project development time, and the amount of money it will cost.

As the customer advocate to the team, the leader of the Product Management role is responsible for understanding customer requirements, creating the business case, establishing the shared project vision between the team and the customer, and ensuring that any solution that the team develops meets the needs of the customer by solving the particular business problem.

As the team advocate to the customer, the leader of this role is responsible for high-level communications and managing customer expectations. High-level communications include public relations, briefings to the customer and senior management, marketing to users, demonstrations, and product launches.

Product Management also communicates the initial ship dates the customer expects the team to target. However, successful projects employ a bottom-up scheduling process determined by other team roles, and Product Management must then communicate the achievable ship dates to the customer.

NOTE
The customer (the person paying the bill for the project) will have a set of expectations for the project. Meeting these expectations creates a satisfied customer, which helps define a successful project. Once a project's vision is set, the key role for Product Management is to manage customer expectations. Thus, the Product Management role often defines what success and failure are for a project.

Product Management should continually manage customer expectations by asking the question "Did we do what we said we would do?" Suppose a project had an initial goal of delivering five features for $10,000 in two weeks, but instead delivered three features for $7,000 in one and a half weeks. Was this project a successful one for the customer? From a Product Management view, we would say, "We agreed with the client on the second day which of the most important features could be done within the budget and the time frame. We met those goals, so the project was successful. We've started a second project for the other two features and two additional features." Product Management included the customer in the tradeoff, demonstrated the decision-making process, and informed the customer of the changing risks and challenges. (The standard challenges are cost control, resource allocation, product features, and the product completion date.) When everyone involved with the project can say, "Yes, we did what we said we would do," trust and respect are built among team members and with the customer.

NOTE
Poorly communicated expectations are the primary reason so many projects fail. When a project's features, resources, or ship date change, whether planned or not, the expectations of the customer, the users, and all project team members should be reset.

The Product Management team represents the interests of the customer and helps the customer identify and prioritize the features of the product. Because the customer has final signoff on which features can wait for a later release and which features must appear in this release, Product Management facilitates this decision by ensuring communication between the customer and the team. Program Management may be asked to remove features from the current release to meet the product ship deadlines, because Program Management is responsible for the schedule and for determining how long it takes to deliver the agreed-on feature set. If Program Management determines that a feature must be cut to maintain the schedule, the customer and Product Management can agree or not agree. However, if the customer and Product Management decide that the feature must stay in this version, they must also agree that Program Management can change the schedule and the ship date. Alternatively, the customer and Product Management may choose to spend more money to allow the addition of members to the project team. Program Management will determine where and how the money is spent, as well as whether the addition will in fact improve the schedule. The customer and Product Management will approve the overall cost of the project.

CAUTION
Applying additional resources to projects does not always decrease time schedules, because communication and management overhead increases.

Within the project team, the term Product Champion might be used to describe the leader of the Product Management role. Often, the Product Champion will be a member of the organization's senior management team. The other people assigned to the Product Management role will be the individuals with the strongest understanding of the organization's structure, business, and strategic goals.

NOTE
If the project team is a consulting group or vendor for a project, Product Management will have two sets of customer expectations to meet: those of the consumer, who sponsors the project and foots the bill, and those of the customer, who is typically the IT person who engages the consulting group and pays for its services. Typically, the consulting group will need to rely on its expertise to explain the organization's use of MSF and how both the consumer and the customer will work with the project team within this framework.

Program Management

The job of the Program Management role is to own the development process and to drive the process to ensure the product is delivered within the project constraints. The leader of this role must understand the difference between being a leader and being a boss. In his book Dynamics of Software Development (Microsoft Press, 1995), former Microsoft Program Management team director Jim McCarthy writes:

Keep in mind that the goal is to endow each person on the team with the fullest possible authority, not to rake it in for yourself.

The primary responsibility of the leader of the Program Management role is to move the project through the development process to ensure that the right product is delivered at the right time. Through leadership, facilitation, and consensus building, this leader coordinates all the other team leaders and their particular responsibilities. Although occasional scheduling pressures may mean the Program Management leader must prod the team firmly back on track, he or she should forget the dictatorial management style.

The leader of Program Management owns the overall schedule for the project, which has been built from the bottom up by the other roles within the project team. He or she coordinates the creation of the project's master schedule with the other team leaders. Any overrun or buffer time for the project is owned by and applied at the appropriate time by Program Management. When individual portions of the project are completed ahead of or behind schedule, Program Management determines the impact on other roles and coordinates schedule changes.

The skills needed for the Program Management role include a strong understanding of the business side of the organization as well as a solid understanding of the technology currently used by the organization and the technology needed for the project. The leader of the Program Management role must possess strong organization skills and strong communication skills.

In organizations that are new to MSF, Program Management often requires a much deeper understanding of the framework and processes that enhance the efficiency of the rest of the team and its leaders. Although leadership characteristics are important for all roles, this expertise is particularly important in Program Management. To be most effective, the Program Management team should have the respect of the other team members before the project begins, including the business, technical, and senior management groups. Typically, the Program Management team will include the administrative resources used by other team roles, as well as support for scheduling and coordinating various meetings among the different team roles.

As the owner of the project's feature set, Program Management defines which features will be delivered in order to meet the agreed upon requirements. Product Management may determine critical requirements, but Program Management determines which particular product features meet those requirements. Additionally, Program Management recommends to the customer which features may be negotiated for future versions given time and money constraints. Program Management owns the features outlined in the Functional Specification (what will be built) and the Master Project Plan (how it will be built). Program Management also coordinates and facilitates the creation of these documents by getting input from each of the team members. It's essential that each member contribute his or her input and approve the Functional Specification and Master Project Plan.

CAUTION
It's important for the Program Management leader to remember that team members have a much deeper knowledge of their particular responsibilities than he or she has. Program Management needs to rely on them, trust their expertise, and yet still provide the overall framework to deliver the whole product within all project constraints.

As the owner of the project's budget, Program Management facilitates the creation of the planned cost by gathering resource requirements from all of the roles on the team. Program Management must understand and agree with all resource decisions (hardware, software, people, and so on) and must track the actual costs against the planned costs. However, the Program Management leader will need to provide regular status reports to the team and key stakeholders throughout the project. Another symptom of failed projects is the delay of status report delivery until after the budget has been exceeded. It's important to remember that adding additional funding is a tradeoff and is therefore a decision that should be made by Product Management and the customer.

Development

The job of Development is to be technology consultants and product builders. As technology consultants, Development provides input into high-level designs, evaluates technologies, and develops prototypes and proof-of-concept systems to validate potential solutions and to mitigate development risks early in the development process. To succeed in meeting its quality goal, it is important that Development focus not only on coding certain aspects of the project according to the Functional Specification, but also on solving the business problem. As a result, Development must innovate, but only to solve the customer's problem, not just for the sake of implementing interesting features. Often to improve envisioning and communication, Development will create prototypes, and to test technology that is new to the organization, the group will create proof-of-concept systems. These systems may also provide ways to communicate architectural decisions to the rest of the team.

As builders, Development provides a low-level product and feature design, estimates the effort required to deliver that design, and then builds the product. In many organizations, a few senior members of the Development team drive the architecture for the product. These architects are involved in the early phases of a project, fleshing out the details of the Functional Specification and determining the appropriate internal and external system interactions for the product.

Development estimates its own schedules because it is responsible for the daily coding work. This MSF concept of schedules being created by those responsible for the work is called bottom-up scheduling. It is an important factor in delivering the right product at the right time. The goal is to achieve a higher quality schedule and to increase accountability for the estimates and for the work.

Development's responsibility for the technical implementation of the project's features primarily falls within the Logical Model and Physical Model of the Enterprise Application Model discussed in Chapter 2. Development determines exactly how to implement each feature, the actual architectural implementation, and how long the coding portion of the project will take to implement. Development does not determine which features to implement, but how to write the code for the product.

In addition, during the Planning Phase of a project, Development must be able to determine the impact on the schedule of adding and removing features. During the late phases, Development is not specifically responsible for the actual deployment of the product, but it must work closely with Logistics Management to understand what installation and setup routines will be needed.

CAUTION
The person assigned as the leader of the Development role should not be assigned to any other roles. The goal is to let the developers do what they do best: write "killer code."

Testing

The job of the Testing role is reality induction. Testing must be able to clearly articulate both what is currently wrong with the product, and what is currently right with it, so that the status of the product's development is accurately portrayed. Performing a valid test requires a good grasp of the needs of the users and a clear understanding of what the product will do to meet those needs. Testing develops test strategies, plans, schedules, and scripts.

The goal of Testing is to make sure that the team knows and addresses all issues before releasing the product. An issue is anything that prevents the product from meeting its requirements. It can be a fault in the Development team's code (known as a bug), a deviation from the Program Management team's specification, or a defect in the User Education team's documentation.

NOTE
It's important to distinguish between Testing and total quality assurance (TQA). Testing has a project focus and involves detailed technical work. TQA, on the other hand, is often a corporate function organized under a Director of Quality, whose responsibility is process compliance with corporate, government, or other regulatory standards.

The same people should not be assigned to the Testing and Development roles. Two key reasons for such a separation are:

Better, independent assurance that coded products truly meet the requirements.

The ability to exploit the concurrency of two working teams.

Testing's independent assessment should verify that Development has met its quality goals, but it is everyone's responsibility, not just Testing's, to ship a good product.

CAUTION
It is the Development team's responsibility to write quality code. Separating the Testing role from the Development role does not remove the responsibility of code quality from the Development team.

Change Control

The project will need a change control process and system. Committing to the change control process is everyone's responsibility, though implementing the change control system often falls to Testing. Developers have used source code control systems such as Microsoft Visual SourceSafe for years, but this type of system provides only revision control. All project artifacts, such as documents, agendas, functional specifications, source code, and compiled code, must be placed under revision control, but revision control is only a portion of change management. As an example, simply turning on revision marks in Microsoft Word does not ensure that the correct edits are made and that the correct information is presented. Thus, change management incorporates many additional steps, including:

Creating a baseline.

Determining which elements should change.

Determining how the change will affect existing systems, processes, or documents.

Identifying how the change will be implemented.

Identifying who will implement the change.

Determining the impact the change will have on project constraints, budget, schedule, and politics.

Determining who makes the change-approval decision.

Implementing the change.

Creating a new baseline that includes the change.

CAUTION
Change proposals should be evaluated in batches to prevent the project team from being overwhelmed or distracted from daily work plans.

Compiling Source Code

A few important responsibilities of Testing are often overlooked:

Bug reporting and tracking As with change management, implementing the bug reporting and tracking system is also the responsibility of the Testing team.

Building the product Someone must be responsible for building (compiling) the product, and often this Build Meister is a member of the Testing team. The Build Meister should use only the source code that is stored in the revision control system. Compile scripts can automate much of the tedium of building code; however, ensuring that the build occurs properly is important.

Risk tracking and management Ongoing risk tracking and management are the responsibility of all teams. Program Management should provide a common method for tracking risks, such as using Microsoft Excel spreadsheets. The Testing team's role is "reality induction," meaning that it provides an outside view of development risks and schedule.

CAUTION
Risk plans that are created or updated five minutes before a project review meeting are useless. Teams should be managing risks as a continuous, ongoing process to help ensure that quality products can be delivered on time.

User Education

The job of the User Education role is to enhance user performance so that users are as productive as possible with the product. To accomplish this goal, User Education acts as the advocate for the users of the product, much like Product Management acts as the customer advocate. However, this is a two-way street, because User Education also acts as the team's advocate to the users of the product.

As the user advocate to the project team, User Education participates in the design process to ensure delivery of a product that is useful and usable, and that needs as little performance support material as possible. User Education is responsible for usability testing, tracking usability issues, and ensuring that those issues are addressed in the product's user interface (UI) design.

By actively participating in UI design as well as other user enhancements, User Education can have a direct impact on a project by helping to reduce the costs of supporting it in the operations/delivery channel. These ongoing support costs are often not adequately considered for many software products. However, the cost-benefit calculation is very simple: The easier a program is to use, the lower the ongoing user support costs.

CAUTION
Do not fall into the budgetary trap of assigning unrealistic user productivity gains that grossly overestimate the total ROI for a project.

Too often projects roll into production without a training plan or consideration of how the users will actually learn to use the product. Where user performance support materials are required, User Education designs, builds, and tests the materials that will enable easier use. These materials can include reference cards, keyboard templates, user manuals, online help, wizards, Web pages, and even full-featured courseware. Once the support materials are created, User Education coordinates the appropriate training for the user community.

Just as it is important for Product Management to manage the expectations of the customer, it is important for User Education to manage the expectations of the user community. However, users shouldn't be expected to be able to understand the language of the Functional Specification. Using prototypes to communicate business and technical requirements to the user community greatly improves the success of the project. Additionally, users will feel progress is being made when they actually see screens and working portions of programs. Although marketing is the responsibility of Product Management, it is important to keep users informed. Randomly posted signs, e-mails about new features or functionality, and beta test programs are excellent methods of communicating with the user community.

NOTE
In cases where an application is being developed for another organization, the User Education role is still important. The consulting organization can't expect the IT person who is paying the bill to adequately represent or interact with the user community. Just as Product Management manages customer expectations, User education manages those of users. Successful projects never spring new products on users and expect that they will love the features. Adequate preparation and training are always essential.

Logistics Management

The job of the Logistics Management role is to serve as the advocate for the operations, product support, help desk, and other delivery channel organizations, and to focus on the smooth deployment and ongoing management of the product. Logistics Management participates in the design process to help ensure that the product is deployable, manageable, and supportable. This role is responsible for creating the deployment schedule. Logistics Management, Product Management, and Program Management work together to determine which users and sites will receive the product in what order. Logistics Management then prepares the sites to receive the product.

For large projects, the Logistics Management team leader should have experience with large-scale product deployments to several thousand desktops. Logistics Management is responsible for the entire deployment of the product to all desktop systems, and requires both a strong technical background and excellent communication skills. Logistics Management also oversees the technicians or contractors who install, configure, and migrate the users' systems. Additionally, this role requires experience in estimating and coordinating software installations.

Logistics Management is responsible for understanding the product's infrastructure and its support requirements. All installation sites, as well as all user systems, must meet those requirements before the product can be deployed. Typically, this is facilitated through the creation and implementation of rollout, installation, and support plans. Significant advances in Microsoft Windows 2000, the Active Directory, and System Management Server have greatly decreased the deployment effort required to target and touch user systems.

Although Logistics Management's primary responsibility is to smoothly deploy the product to all users, the leader of this role also needs to create an ongoing support plan and ensure that existing support groups are able to help users. Just as important as training the user community is providing training to the operations and help-desk personnel. The training process must involve these groups early in the product's life cycle and during the beta-test phase. Formal support documentation, backup and restore requirements, and disaster-recovery plans must be created for the product before it is handed off to the operations group. For a fixed period after turning a product over to operations, Logistics Management should plan on providing the operations group with technical support. It is difficult to anticipate all the problems and issues that will arise from a fully deployed application, so Logistics Management must plan for the unexpected.

Other Logistics Management activities include supporting interim operations and supporting the product during the development process. Logistics Management will often be required to assist in monitoring the applications' behavior within the test environment. Additionally, this role provides initial support for the software during the production process in the form of development systems, test systems, certification, and production systems. Product support for the quasi-production process used during the beta-testing phase must also be provided.

Many organizations have specific systems that provide real-time monitoring for performance and stability. The Logistics Management team should provide the Development team with the appropriate information and technical contacts to integrate the new product into current and future management tools. For example, incorporating ongoing product management into Microsoft Management Console (MMC) will help support organizations easily integrate the product with other Microsoft systems.

The aggressiveness of the deployment schedule, the automation level of the installation, the use of automated software delivery tools, and the migration processes created by the Development team will determine the size of the Logistics Management team.