Tài liệu Module 4: MSF Team Model doc

Contents
Overview 1
Team Goals for Success 2
The MSF Team Model 5
Principles of a Successful Team 16
Review 21

Module 4: MSF Team
Model


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 1999 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, and Windows NT are either registered trademarks or

trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

MOC Project Advisor: Janet Wilson
MOC Project Lead: Sharon Salavaria
Program Manager/MSF Project Manager: Sharon Limbocker
Program Manager/Technical Consultant: Dolph Santello
Instructional Designer: Marilyn McCune (Independent)
Product Manager: Jim Wilson
Product Manager: Jerry Dyer
Graphic Artist: Andrea Heuston (Artitudes Layout & Design)
Editing Manger: Lynette Skinner
Editors: Marilyn McCune (Independent) and Wendy Cleary (S&T Onsite)
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Bo Galford
Lead Product Manager: Development Services: Elaine Nuerenberg
Lead Product Manager: Mary Larson
Group Product Manager: Robert Stewart

Module 4: MSF Team Model iii


Instructor Notes Module 4: MSF Team Model
This module provides students with an introduction to the Microsoft Solutions

Framework (MSF) Team Model, including the team goals for success, team
roles of the model, how to scale the model for small or large projects, principles
of a successful team, and how to apply the model to different types of projects.
At the end of this module, students will be able to:
 Describe the six team goals for a successful project.
 Name the six roles of the MSF Team Model.
 Define feature team and function team, and describe the function of each.
 Describe the fundamentals of good teaming by defining team of peers,
shared product vision, product mindset, zero-defect mindset, customer-
focused mindset, and willingness to learn, as they apply to successful
teaming.
 Describe what happens to the MSF Team Model when it is applied to an
enterprise architecture (EA) project, an application development (AD)
project, and an infrastructure deployment (ID) project.

Materials and Preparation
This section provides you with the materials and preparation needed to teach
this module.
Materials
To teach this module, you need the following materials:
 Microsoft® PowerPoint® file 1639a_04.ppt
 Module 4, “MSF Team Model”
 A flip chart or white board

Preparation
To prepare for this module, you should:
• Read all the materials for this module.

Presentation:
60 Minutes

Activity:
15 Minutes
iv Module 4: MSF Team Model


Instructions for Activity A: Designing a Dream House
This activity is designed to reinforce what students have just learned about MSF
Team Model roles and responsibilities.
In this activity, the instructor creates three teams of four students. Assign the
following roles to each team: product manager, program manager, programmer,
and customer.
Each team is assigned the task of designing the customer’s dream house. In
each team, the customer sits apart from the others and is unable to overhear and
participate in the discussion. Only the product manager has contact with the
customer.
 The first team has no contact with the customer.
 The product manager in the second team can meet with the customer once.
 The third team uses the versioning process, so the product manager can
meet with the customer after each design revision.

The teams have five minutes to complete the task. There is a penalty for each
minute over five minutes. At the end of five minutes, each team presents the
house design to the class. The customer gives rates the design on a scale of 1 to
10. One point is deducted for each minute over five minutes.
Because the third team had several interactions with the customer, their design
should be closest to the customer’s expectations.
Estimated time to complete this activity: 15 minutes
Objective
• Following is the learning objective for this activity:

The student will be able to describe the fundamentals of good teaming,
including a team of peers, shared product vision, product mindset, zero-
defect mindset, customer-focused mindset, and willingness to learn.

Setup
There are no special setup requirements for this activity.
Module 4: MSF Team Model v


Module Strategy
Use the following strategy to present this module:
 Team Goals for Success
This section presents the team goals for success as identified by MSF.
Topics in this section include:
• The Six Team Goals for Success
• Understanding the Goals

 The MSF Team Model
This section presents the six team roles of the MSF Team Model, and the
relationship between each team role and their corresponding project goal.
Topics in this section include:
• Hierarchical Teams and the Team Model
• Product Management Role
• Program Management Role
• Development Role
• Testing Role
• User Education Role
• Logistics Management Role
• Team and Goal Alignment

 Principles of a Successful Team
The section presents the principles that underlie the Team Model, the basics
of scaling the Team Model for small or large projects, and team role key
responsibilities when the Team Model is applied to different project types.
Topics in this section include:
• Scaling the MSF Team Model
• Applying the MSF Team Model

vi Module 4: MSF Team Model


Background on Scaling the MSF Team Model
Scaling for Small Projects
Although the Team Model consists of six roles, a team does not always require
a minimum of six people. The key is that all six roles must be represented on
every team and that some roles—particularly development—should not be
combined with anything else.
When scaling teams for small projects, keep in mind the following issues:
 Individual team members can have multiple roles within a project.
 Team members responsible for multiple roles should make it clear which
role or roles they represent when they speak or offer guidance.
 Teams can function with fewer than six people.
 Be sure that all perspectives are represented.
 Avoid conflicts of interest.
Not combining Program Managers and Product Managers is just an example
of avoiding conflicts of interest. Product management wants to satisfy the
customer, whereas program management wants to ship on time and within
budget.
 Do not distract the developers.
Developers are the builders and should not be distracted from their main

task by having to take on the tasks of another role on the team. For example,
adding additional responsibilities from outside development to the
development team is likely to slip the development schedule.
 There are no absolutes, however. Ultimately, success in combining roles
depends on the skills of individuals.

Scaling for Large Projects: Feature Teams
The MSF Team Model advocates breaking large teams (more than ten people)
into small, multidisciplinary feature teams and breaking complex or
cumbersome roles into a smaller, focused feature teams.
Referring to the slide, feature teams are small teams that work in parallel,
making certain to synchronize their efforts frequently. The logic behind feature
teams includes the following:
 Feature team members are drawn from four of the six roles that make up the
Team Model. That is because product management and logistics
management tend to focus more at the product level than at the feature level.
 Each team is responsible for all aspects of the feature to which it has been
assigned.
 Feature teams are empowered and accountable because their members have
access to the people that they need for making good decisions.
 Treating large teams as a collection of small teams offers the benefits
enjoyed by smaller teams, such as lower process and communications
overhead and greater flexibility.

Module 4: MSF Team Model vii


Scaling for Large Projects: Function Teams
Function teams are teams that exist within a role and are formed when tasks
within a role are large enough to require dedicated resources. Function teams

are effectively the opposite of feature teams. They are created when a team or
project is so large that it requires grouping people within a role into teams based
on their function. When you create a function team, consider the following:
 Function teams are made up of people fulfilling different aspects of the team
role that they represent. More than one person per role does not make a
function team. It is the delineation of those people by their tasks that makes
a function team.
 A product management function team might have one person focusing on
product planning, whereas another does marketing and yet another does
public relations.
 A development function team might group developers by the service layer
that they work on—for example, user, business, or data. This could occur
within a feature team.


Module 4: MSF Team Model 1


Overview
 Team Goals for Success
 The MSF Team Model
 Principles of a Successful Team
 Scaling the MSF Team Model
 Applying the MSF Team Model


At the end of this module, you will be able to:
 Describe the six team goals for a successful project.
 Name the six roles of the Microsoft Solutions Framework (MSF) Team
Model.

 Describe the fundamentals of good teaming by defining team of peers,
shared product vision, product mindset, zero-defect mindset, customer-
focused mindset, and willingness to learn, as they apply to successful
teaming.
• Describe scaling the Team Model for small and large projects. Define
feature team and function team.
• Describe what happens to the Team Model when it is applied to an
enterprise architecture (EA) project, an application development (AD)
project, and an infrastructure deployment (ID) project.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about team goals for
success, principles of a
successful team, and the
MSF Team Model.
2 Module 4: MSF Team Model




 Team Goals for Success
 The Six Team Goals for Success
 Understanding the Goals

There are six team goals for success that underlie the MSF Team Model
satisfied customers, delivery within project constraints, delivery to
specification, release after addressing all known issues, enhanced user
performance, and smooth deployment and ongoing management.
Slide Objective
To introduce the topics
presented in this section.
Lead-in
The team goals for success
underlie the MSF Team
Model.
Module 4: MSF Team Model 3


The Six Team Goals for Success
 Satisfied Customers
 Delivery within Project Constraints
 Delivery to Specification
 Release After Addressing All Known Issues
 Enhanced User Performance
 Smooth Deployment and Ongoing Management


To be truly successful, every team should strive to accomplish the following
goals:
 Satisfied Customers. Because every project has a customer, satisfying that
customer has to be a principal goal for the project team. Even a project that
meets all other criteria for success is a failure if the customer does not
consider it a success.
 Delivery within Project Constraints. Delivering within project constraints is

crucial. A product late and over budget is not likely to be considered a
success.
 Delivery to Specification. Delivering the product that everyone agreed
should be delivered is also crucial as is making certain that specifications
were built in the first place on what potential users need and want.
 Release After Addressing All Known Issues. The team should not release the
product until it has identified all of the issues and handled them somehow,
whether by fixing them or agreeing to address them in a later release. A
known bug is better than an unknown bug, because future users can be told
about it and offered ways to work around it.
 Enhanced User Performance. The product should do something to improve
user performance, or it had not really met any meaningful needs. The point
of this goal is that even if the product is delivered on time and on budget, it
cannot really be considered a success if it does not enhance a user’s ability
to work.
 Smooth Deployment and Ongoing Management. Finally, a successful team
is one that can deploy a product without great difficulties and make certain
that it is supported in a way that bolsters users’ confidence in the product.

Slide Objective
To present the six team
goals for success that form
the basis of the Team
Model.
Lead-in
The Team Model is built on
principles that include the
six team goals for success,
which become the
responsibilities of the Team

Model roles.
4 Module 4: MSF Team Model


Understanding the Goals
 Overall Success Requires Accomplishment of Each
Goal
 Each Goal Must Be Equally Valued
 Each Goal Requires a Discipline That Is Focused on
That Goal
 Each Discipline Is Embodied in a Role
 Equally Valued Goals Equate to Equally Valued Roles
 Creating a team of functional peers


The key to understanding the six team goals and objectives lies in
understanding that the goals are an “all-or-nothing” proposition. You cannot
achieve success overall unless you accomplish each one of the goals. This point
is crucial to explaining how the six goals map to the team roles.
The connection between the team goal and the team role is based on the
following logic:
 Overall success requires accomplishment of each goal. For the team to
succeed overall, it must succeed with each goal.
 Each goal must be equally valued. The only way to ensure that the team
succeeds is to require that it pay attention to each goal, which means that all
team members must value all six goals equally.
 Each goal requires a discipline that is focused on that goal. The link
between a goal and a role is the discipline applied to a goal that focuses
specifically on accomplishing that goal.
 Each discipline is embodied in a role. Each goal is equally necessary for

success and must be equally valued. In the same way, each role that focuses
specifically on achieving a goal must also be equally valued.
 Equally valued goals equate to equally valued roles. The relationship of
goal and role is the basis for the idea of a team of peers, which is the heart
of the Team Model for application development.

Slide Objective
To present the principles
that correspond to the six
team goals for success.
Lead-in
The team goals for success
assume that overall project
success includes
accomplishment of each
one of the goals.
Key Points
Emphasize that
understanding how the
goals are linked to one
another is important
because it helps explain
how the goals relate to the
six team roles.
Module 4: MSF Team Model 5




 The MSF Team Model

Program
Management
Development
Testing
Logistics
Management
User
Education
Product
Management
Communication


The MSF Team Model includes six team roles that are independent and
multidisciplinary, meaning that each role on the team is a different discipline,
so each team is made up of multiple disciplines.
When the Team Model is applied to different project types, the responsibilities
of each role may change, but the naming of the roles and their focus on their
specific success goals remains the same.
Slide Objective
To present the Team Model
roles.
Lead-in
The MSF Team Model
includes six team roles that
are independent,
interdependent, and
multidisciplinary.
Delivery Tip
Note that all roles exist

within the organization. At
the project level, the six
team roles are involved from
the beginning of the project.
6 Module 4: MSF Team Model


Hierarchical Teams and the Team Model
Testing
Developer
Project
Manager
Logistics
Developer
Analyst
User
Education


The Team Model is not intended to replace a traditional organizational chart; it
is intended to coexist with hierarchical structures and, by doing so, to overcome
issues related to hierarchical structures.
 Some issues are inherent to hierarchical team structures, including the fact
that the hierarchical structure imposes a relatively high overhead, which
may inhibit communications.
 Team members may not communicate clearly unless they understand their
roles and the roles of others on their team.
 Team members who do not communicate directly increase their chances of
being misunderstood.
 Team members are likely to disengage if they do not understand what is

happening or where they are going.
 High process overhead.

To overcome some of the issues inherent in hierarchical team structures, the
MSF Team Model can be integrated to provide:
 Shared team goals for success.
 Clear roles and responsibilities.
 Team of peers.
 Direct communication.
 Team and project goal alignment.
 Flexibility and scalability.

Slide Objective
To show the Team Model in
relation to a hierarchical
model.
Lead-in
The Team Model is not
intended to replace a
traditional organizational
chart; it is intended to
coexist with hierarchical
structures and, by doing so,
to overcome issues related
to hierarchical structures.
Key Points
The Team Model is not
indented to replace
traditional hierarchical
organizational models for

reporting purposes and to
become an organizational
model, but to exist and
operate within traditional
hierarchical organizational
models.
Module 4: MSF Team Model 7


Product Management Role
 Act As Customer Advocate to the Team
 Act As Team Advocate to the Customer
 Drive Shared Project Vision
 Manage Customer Expectations
 Develop, Maintain, and Execute the Business Case
 Drive Feature Identification and Prioritization
 Develop, Maintain, and Execute the Communications
Plan


For the most part, there is no significance to the order in which the six roles of
the Team Model appear. But product management does come first because
projects start with product management in response to a customer need.
The activities of the product manager may vary depending on the type of
project, but common activities carried out by the product manager on any
project include the following:
 Act as a customer advocate to the team. Drive the team to a shared vision of
how to meet customer expectations. There is an important difference
between the customer and the end user—the customer pays for the product,
whereas the end user uses it. This means that the needs of the customer and

those of the end user have important differences, and the team must achieve
a balance between them.
 Act as team advocate to the customer. Handle high-level communications.
 Drive shared product vision. Establish a shared vision between the team and
the customer.
 Manage customer expectations. How well the team manages customer
expectations can determine whether the project is a success or a failure.
Slide Objective
To present the generic
responsibilities of the
product management role.
Lead-in
Projects start with product
management in response to
a customer need.
Key Points
Emphasize that product
management is both the
customer advocate to the
team and the team advocate
to the customer.
8 Module 4: MSF Team Model


 Develop, maintain, and execute the business case. The business case is the
document that justifies the project. Often this maps directly to the MSF
vision document, but it also has existed in parallel. The key point is that
product management is responsible for understanding why this project is
being done.
 Drive feature identification and prioritization. Product management drives

the scope of the project. The use of the term feature in this context refers to
the points of functionality that will later play into the project tradeoff
triangle, in which a balance must be achieved between features, resources,
and schedule.
 Develop, maintain, and execute the communications plan. The
communications plan describes how product information will be relayed to
the customer and users. For an external product, it can be thought of as a
marketing plan. But generally, for internal development, it is thought of as a
communications plan.

Module 4: MSF Team Model 9


Program Management Role
 Drive the Overall Process
 Manage resource allocation
 Own the project schedule and report project status
 Manage the Product Scope and Specification
 Facilitate Team Communication and Negotiation
 Drive Overall Critical Tradeoff Decisions


The program management role can be confusing, because there is so much
about the role that is associated with the role of a lead or manager on a more
traditional team. The program manager is not the lead, however. The program
manager is a leader, facilitator, and coordinator for the project, but is not the
lead.
The activities of program management may vary depending on the type of
project, but common activities carried out by the program management on any
project include the following:

 Drive the overall process. Responsible for delivering the right product at the
right time. The program manager must:
• Own the project schedule and reports project status.
• Manage resource allocation.
 Manage the product scope and specification.
 Facilitate team communication and negotiation.
 Drive overall critical tradeoff decisions.

Slide Objective
To present the generic
responsibilities of the
program management role.
Lead-in
Program management
leads, facilitates, and
coordinates the project.
Key Points
Emphasize that the program
manager acts as a leader,
facilitator, and coordinator of
the project, but is not the
lead. This point is important
to the concept of the team of
peers discussed in a
preceding topic.

Secondly, emphasize that
ultimately the program
manager is responsible for
the scope and shape—or

specification—of the
product.
10 Module 4: MSF Team Model


Development Role
 Build and Test the Product to Meet Specifications and
Customer Expectations
 Participate in product design
 Estimate time and effort to complete the product
 Serve the team as a technology consultant
 Support product installation and deployment
 Develop, configure, and customize the product


The activities of the development role may vary depending on the type of
project, but common activities carried out by the development role on any
project include the following:
 Build and test the product to meet specifications and customer expectations.
Because the developer is responsible for building the product the customer
wants, the developer must:
• Participate in product design. This ensures that the developer has a
complete understanding of product specifications and customer
expectations, even though the primary focus of the developer is on
physical design.
• Estimate time and effort to complete the product. The result of this
estimate will determine the team’s overall product schedule.
• Serve the team as a technology consultant. Early in the development
process, developers provide input into high-level designs, evaluate
technologies, and help to validate potential solutions and mitigate risks

as technology consultants.
• Support product installation and deployment. Developers may be
required to write project-specific scripts and develop code that will aid
the team in installing and deploying the product.
• Develop, configure, and customize the product. Ensure that product
meets customer expectations.

Slide Objective
To present the generic
responsibilities of the
development role.
Lead-in
The developer on a team is
there for only one reason—
to build the product.
Delivery Tip
If the question is asked,
then why does this slide
show the responsibilities as
sub-objectives? Emphasize
that the primary goal of the
developer role is to build the
product.
Module 4: MSF Team Model 11


Testing Role
 Develop Testing Strategy, Plans, and Scripts
 Manage the Build Process
 Conduct Tests

 Participate in Setting the Quality Bar


The purpose of the testing role is to be able to accurately portray the status of
the product at any time by clearly stating what is currently wrong and what is
currently right with the product.
The activities of the testing role may vary depending on the type of project, but
common activities carried out by this role on any project include the following:
 Develop test strategy, plans, and scripts. The testing role should have a
good understanding of user needs and of how the product will meet those
needs.
 Manage the build process. On smaller projects, the testing role will be
responsible for the build process of a product, but on a larger project a build
team will typically be dedicated to the build process.
 Conduct tests. The testing role conducts tests to accurately determine the
status of product development.
 Participate in setting the quality bar. The testing role contributes to
determining the tolerable zero-defect level by which the team will measure
product success or failure.

Slide Objective
To present the generic
responsibilities of the testing
role.
Lead-in
The testing role carries out
the following activities
Key Points
Testing should not be
confused with quality

assurance. Testing has a
project focus, whereas
quality assurance is often
responsible for compliance
with corporate or regulatory
standards.
12 Module 4: MSF Team Model


User Education Role
 Act As Team Advocate to the End User
 Act As End-user Advocate to the Team
 Participate in Defining User Requirements
 Participate in Designing Features
 Design and Develop User Support Systems
 Drive the Usability Process


The goal of the user education role is to enhance end-user performance so that
end-users can be as productive as possible when using the product. It is
important in this context to distinguish between the customer and the end user;
the customer pays for the product, but the end user is the one who must use it.
The activities of the user education role may vary depending on the type of
project, but common activities carried out by this role on any project include the
following:
 Act as team advocate to the end user. Often it is the performance support
materials that user education creates that represent the team to the end user.
Through these materials, user education must be an advocate for the team
and must help in managing end-user expectations.
 Act as end-user advocate to the team. User education is expected to have a

thorough understanding of the user community and of user needs and is
responsible for representing users to the project team, from envisioning
through stabilization and release
.
 Participate in defining user requirements. User education conducts usability
studies and gathers information, such as user-requested features and
customer support, in order to provide it to the project team.
 Participate in designing features. User education participates in design with
the goal of minimizing the need for user support material and lowering the
cost of such materials.
 Design and develop user performance support systems. If the product needs
any performance support materials, user education designs, builds, and tests
them. Performance support materials might include such things as reference
cards, keyboard templates, user manuals, online Help, wizards, and even
full-featured courseware.
 Drive the usability process. User education tests and tracks usability issues
and ensures that the product design addresses these issues.

Slide Objective
To present the generic
responsibilities of the user
education role.
Lead-in
The user education role
carries out the following
activities
Key Points
User education’s advocacy
role is also two-way, as is
that of product

management. User
education is the team
advocate to the end user
and the end-user advocate
to the team.
Module 4: MSF Team Model 13


Logistics Management Role
 Act As Team Advocate to Operations
 Act As Operations Advocate to the Team
 Manage Product Deployment
 Participate in Design
 Support the Product During Beta Testing
 Train Operations and Personnel for Product Release


The activities of the logistics management role may vary depending on the type
of project, but common activities carried out by this role on any project include
the following:
 Act as team advocate to operations. Logistics management is the team
representative to the operations and support groups and works to manage
their expectations.
 Act as operations advocate to the team. Logistics management is
responsible for understanding the needs of operations and support personnel
and representing those needs to the team to ensure that the product is
deployable, manageable, and supportable.
 Manage product deployment. Logistics management is responsible for a
planning and managing a smooth deployment of the product and for
ensuring that the product is manageable and supportable in the future.

 Participate in design. Logistics management focuses on product
manageability, supportability, and deployment. It advises the team on
manageability and supportability issues based on lessons from previous and
current product deployments.
 Support the product during beta testing. Acts as interim operations and
support for the product during the development process.
 Train operations and personnel for product release. Logistics management
may be required to provide operations support with technical documentation
for such things as setup and platform configurations.

Slide Objective
To present the generic
responsibilities of the
logistics management role.
Lead-in
The logistics management
role is responsible for
carrying out the following
activities
Key Points
Much like product
management and user
education, logistics
management is also a two-
way advocacy role—it is the
team advocate to operations
and the operations advocate
to the team.
14 Module 4: MSF Team Model

Team and Goal Alignment
Team role
Product management
Program management
Development
Testing
User education
Logistics management
Goal
Satisfied customers
Delivery within project constraints
Delivery to product specifications
Release after addressing all
known issues
Enhanced user performance
Smooth product deployment


The six roles of the Team Model for application development correspond
directly with the six key quality goals for an effective project team, which helps
the team maintain appropriate checks and balances. Having clearly defined
roles and goals increases responsibility and ownership.
 Although it is true that the whole team is responsible for the project’s
success, tying individual goals to individual roles ensures accountability and
focus.
 Each goal requires a different discipline and creates a unique mindset. Each
team role brings that discipline and mindset to bear on meeting the overall
goal of project success.
 A well-balanced team has members who represent the perspective of all six

of the fundamental Team Model roles.

Slide Objective
To present the relationship
between each team role and
their corresponding project
goal.
Lead-in
Each team role corresponds
with a project quality goal.
Key Points
This alignment is at the
heart of the Team Model—
six equally valued goals
aligning with six equally
valued roles, each of which
provides the unique
approach that is needed to
accomplish each goal.
Module 4: MSF Team Model 15


Activity A: Designing a Dream House


This activity is designed to reinforce what you have just learned about MSF
Team Model roles and responsibilities.
In this activity, the instructor creates three teams of four studentsStudents on
each team will be assigned one of the following roles: product manager,
program manager, programmer, or customer.

Each team is assigned the task of designing the customer’s dream house. In
each team, the customer sits apart from the others and is unable to overhear and
participate in the discussion. Only the product manager has contact with the
customer.
 The first team has no contact with the customer.
 The product manager in the second team can meet with the customer once.
 The third team uses the versioning process, so the product manager can
meet with the customer after each design.

The teams have five minutes to complete the task. There is a penalty for each
minute over five minutes. At the end of five minutes, each team presents the
house design to the class. The customer gives rates the design on a scale of 1 to
10. One point is deducted for each minute over five minutes.
Estimated time to complete this activity: 15 minutes
Slide Objective
To introduce the activity.
Lead-in
In this activity, you will apply
what you have just learned
about the six roles of the
MSF Team Model.
16 Module 4: MSF Team Model




 Principles of a Successful Team
 Team of Peers
 Shared Product Vision
 Product Mindset

 Zero-Defect Mindset
 Customer-Focused Mindset
 Willingness to Learn


Creating a successful team requires more than defining roles and
responsibilities. There must also be underlying practices and principles. The
following are some, but not all, of the best practices and principles that have
helped make the Team Model a success:
 Team of peers. It is not an overstatement to say that the Team Model could
not function without a team of peers in place, it relies on having each of the
six roles filled by a person or persons who is accomplished at the tasks of
that role.
The Team Model only works if each member of the team is trusted to do his
or her part of the job and, in turn, feels responsible for doing his or her job.
 Shared product vision. A project’s success depends on the ability of project
team members and the customer to share a clear understanding of the
project’s goals and objectives.
The vision should be formalized as a vision statement that describes both
what the project is and is not, enables decisions, motivates the team, and is
achievable.
 Product mindset. A product mindset helps connect work to a project and the
results of the project to the product. MSF advocates creating project
identities that enable members to clearly identify their team, their goals, and
their contribution to the project. For example, you can use project code
names to represent the team and the work.
 Zero-defect mindset. A zero-defect mindset is a commitment to do the
highest possible quality work.
It does not mean having the unrealistic goal of shipping a product with
absolutely no defects at all. If each team member does his or her best job

possible, the overall quality of the product will be raised. This is important
in the long run because it makes for a better product, and, because the
product will have fewer defects and take less time to reach stability, it will
be easier to predict when the product will ship.
Slide Objective
To introduce the topics
presented in this section.
Lead-in
Part of creating a successful
team includes making the
following principles a
priority.
Module 4: MSF Team Model 17


 Customer-focused mindset. Having the customer actively participate in and
offer feedback throughout the project life cycle enables the team to better
manage customer expectations and achieve a better alignment with customer
needs.
 Willingness to learn. Learning has to be made an explicit activity—for
example, by dedicating time in the schedule—for it to have the desired
effect.

Milestone reviews and postmortems enable teams to make mid-course
corrections to avoid repeating mistakes and to create best practices out of
the things that went well. Capturing and sharing best practices are
fundamental to ongoing improvement and continuing success.