02.building a msf team

Module 2: Building an
MSF Team

Contents

Module Overview 1
Lesson: The MSF Team Model 2
Lesson: MSF Role Clusters 15
Lesson: Scaling Teams for Project
Efficiency 28
Lesson: A Scalable Approach to Project
Management 40
Module Summary 51

Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

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.

 2002 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, BizTalk, MSDN, and PowerPoint are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.

The trademark “PMBOK” is a registered mark of the Project Management Institute, Inc., in the
United States and/or other nations.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.

Module 2: Building an MSF Team iii

Instructor Notes
This module provides students with a high level introduction to building a team
that should enable students to be effective participants (as opposed to leads) on
an MSF team.
After completing this module, students will be able to:
! Discuss how six of the eight MSF foundational principles apply to the team
model.
! Identify the major project goal that is associated with each team role cluster
on an MSF project.
! Identify how to organize an MSF Team with a specific number of
participants.
! Discuss how project management in MSF is distributed among team leads
on large projects.

Required materials To teach this module, you need the following materials:
! Microsoft® PowerPoint® file 1846A_02.ppt
! Materials listed in the Activities Appendix for the “Communicating in
Teams” activity

Important It is recommended that you use PowerPoint 2002 or later to display
the slides for this course. If you use PowerPoint Viewer or an earlier version of
PowerPoint, all the features of the slides may not be displayed correctly.

Preparation tasks To prepare for this module:
! Read all of the materials for this module.
! Review the MSF Team Model white paper on the Microsoft Solutions
Framework Web site at http://www.microsoft.com/msf.

iv Module 2: Building an MSF Team

How to Teach This Module
This section contains information that will help you to teach this module.

Lesson: The MSF Team Model
This section describes the instructional methods for teaching this lesson.
Lesson: MSF Team
Model
Purpose
To set expectations for student learning in this lesson.

Delivery
! Explain that this lesson focuses on the rationale for how the MSF team
model was organized and the roles identified.
! Read the objectives on the slide.

Activity: Communicating Purpose
in Teams
To announce the communicating-in-teams activity.

Delivery
See activities delivery section in the instructor guide.
Symptoms of Purpose
Challenged Projects
To discuss some typical problems with challenged or failing projects.

Delivery
This is a 2-build slide.
! Build 1. This shows the first group of quotes, which were made by
customers and users of a solution.
! Build 2. The second group of quotes comes from team members who
participated in the project.
! Note that all the quotes have been chosen because they are representative of
typical types of problems encountered in projects.
! Ask students if these quotes sound familiar.

Module 2: Building an MSF Team v

Goals for Successful Purpose
Projects
To demonstrate how the basic goals for successful projects contain the remedies
for common project failures.

Delivery
! Build 1. Ask students to notice that the complaints listed here are the ones
we saw in the previous slide, except for the last one, which generalizes the
team member complaints.
! Build 2. Explain that success in a project can be promoted by clearly
defining goals that relate to typical complaints and seeking to prevent the
problems that are behind them.
• Show how the goals relate to the complaints by discussing one example,
such as the following:
Example: Established completion dates and budgeted costs represent
project constraints, so a recommended goal that would answer to
complaints about lateness and excessive expense would be that the
solution should be delivered within the constraints agreed to at the
beginning.
• Conclude by asserting that although each project has its own success
criteria, defined in the vision/scope, the goals shown in the slide are
basic ones that apply to all IT projects.
• Use some of the scenarios supplied by students in Module 0 to
emphasize that all of the goals must be met in order for the project to be
deemed a complete success. Challenge students to think of a project that
could be deemed a complete success while failing to meet one of the
project goals.
! Build 3. Show the third column. Suggest that after goals have been
established, the question becomes, “Who has ownership of these goals—
who should be responsible for achieving them?”

vi Module 2: Building an MSF Team

MSF Team Model Purpose
To use the team model graphic to help students understand the way the MSF
team model is structured and the reasons for this structure.

Delivery
! Build 1. Tell students that MSF has constructed the team model to ensure
that all project goals can be achieved by naming a role (role cluster) that
will “own” each goal.
! Build 2. Explain the visual elements of the model.
• Point out that communication is located at the center of the model. This
indicates that it is central to the functioning of the model, that it must
take place between all roles, and that it is the responsibility of all roles.
Recall to students the frustrations expressed by team members about
challenged projects and how many of them were related to
communication.
• Point out that each role cluster is the same size on the model, signifying
that each of the role clusters (or roles as we will generally refer to them
for the sake of simplicity), is equally important to the success of the
project.
• Also point out that each role cluster is a different color, a reminder that
although the roles are equally critical, they each bring a unique
perspective and a unique set of skills and knowledge to projects.
• Acknowledge that the most prominent structural feature of the model is
that it is circular. Explain that the circle represents these ideas:
• The non-hierarchical nature of the model.
• The idea of inclusion, encouraging all team members to see
themselves as an integral part of the solution.
• The interconnectedness and interlocking responsibilities of the role
clusters.
! Build 3. To avoid confusion, emphasize that the team model with its role
clusters:
• Does not represent an organizational chart.
• Does not define a management structure.
• Usually includes members from different organizations to fill roles on
the project teams.
! Recall the team communication exercise completed earlier and emphasize
that the MSF team model was designed to:
• Avoid the failure of information to reach everyone who needs it that
often happens with top down communication approaches.
• Avoid the misunderstandings and disengaged members that hierarchies
tend to cause.

Module 2: Building an MSF Team vii

Note Do not drive deep into the roles, because each will be covered in depth
later. Emphasize here the fact that although there are six role clusters, this does
not mean there are always six people per project team. The details of scaling
project teams will be discussed later; however, students often have difficulty
with the distinction between a role and the person or persons filling it. Explain
the difference right away to counter any thoughts that a role (cluster) is equal to
an individual. (Also, see Background below.)

Background
The role cluster names are sometimes also used as job titles in the industry.
However the distinction between job titles and the MSF role names should
remain clear—that the purpose of the role is to associate a name with a key goal
for project success, whereas job titles fulfill an organizational need for labeling
positions.
Other Project
Participants—External
Purpose
Stakeholders To define the various parties outside the team that it communicates with
throughout the project.

Delivery
! Tell students that in order to achieve its goals, the team must identify key
individuals or groups with whom they will work on the project and who
have a “stake” in its outcome. These people are commonly known as
external stakeholders.
! Read the definitions on the slide of the common stakeholder names as they
will be used throughout this course, giving examples from your experience
of the difference between customer, project sponsor, and end user.
! Emphasize that not only do teams need to be aware of who their external
stakeholders are—they also need to establish working relationships with
them.

Note Instructors may need to refer back to this slide before or during the
presentation of the slide and graphic “The Extended Project Team” that shows
the internal team members who interact with these parties.

viii Module 2: Building an MSF Team

MSF Foundational Purpose
Principles Applied to
To explain how MSF foundational principles guide the functioning of the team.
Team Model
Delivery
Note There are six principles that are especially relevant to the team. These
will be covered in two slides. This would be a good time (while discussing the
principles) to refer back to the students’ flipchart list of reasons for project
successes and failures, if any are related to the principles.

! Build 1. Explain to students that understanding how the MSF team model
contributes to successful projects requires understanding six foundational
principles in MSF that are particularly relevant to it. This slide and the next
one explore these principles, which guide the team in its functioning—how
it approaches the work and how team members relate to one another and to
external project stakeholders. Mention that the principles also have
applications in the other MSF models and disciplines, so students can expect
to see them mentioned throughout the course.
! Explain that MSF views working towards a shared vision as a basic
requirement for the team to function successfully as a team and the essential
start to the solution delivery process. The discussions required to arrive at a
shared vision accomplish these things:
• Bring individual assumptions to light and enables the team to resolve
discrepancies.
• Clarify project goals and objectives, revealing individual assumptions
and enabling the team to resolve discrepancies.
Once in place, the shared vision:
• Ensures that efforts are aligned and work is done in service of the goal.
• Motivates team members to have a uniform sense of purpose.
• Provides an agreed-upon yardstick for measuring success.
Example: For Microsoft® Windows NT® 3.51, the shared vision, simply
stated, was “improving performance.” Everything the team did was in the
service of this goal. Accordingly, the internal code name for the project was
Daytona, a reference to the high performance cars that race on the Daytona
race track.

Module 2: Building an MSF Team ix

! Build 2. Explain that the team is expected to focus on business value
throughout the project, from the initial setting up of project goals through
the entire series of team decisions made during the life of the project. A
successful solution must deliver value or benefit to the customer. The team
maintains this focus by:
• Asking that all team members have a sound understanding of the
customer’s business in order to be able to recognize business value.
• Designating the product management role as the customer advocate.
• Providing for active customer participation in project delivery,
sometimes in the product management role.
Example: Remind students of the brick and mortar stores discussed in
module 1. Such a store might want to attract new customers or keep
customers who are abandoning them to shop online. The store might decide
to build its own Web site in order to give its customers multiple ways of
shopping and retain their loyalty. Despite all of the exciting technical
features that can be built into Web sites, the team must focus on the business
goals in their solution.
! Build 3. Explain that the MSF principle “stay agile, expect change” stems
from the belief that change in the project environment is inevitable during
the course of a project, and that a team must have the ability to become
aware of these changes and respond appropriately. Changes in requirements
for the project can come from such different sources as:
• Technology developments.
• Business pressures.
• New regulations.
• User feedback about early prototypes.
! Explain that the MSF team structure incorporates agility by ensuring that all
core roles are available throughout the project to explore and review
decisions based on the change from their unique perspectives.
Example: During the development of one version of Microsoft Money, a
new version of Quicken, a competing product, was released. When it started
to cut into Money’s market share, the Money team dropped features and
shipped in order to stay in the market. In this case the change was a matter
of competitive pressure and the team proved their agility by quickly
modifying the scope of the project.

x Module 2: Building an MSF Team

MSF Foundational Purpose
Principles and Team
To present the second group of foundational principles that guide the
Model (continued)
functioning of the team model.

Delivery
! Build 1. Explain that MSF views the empowerment of team members as
essential in enabling team members to make and meet commitments.
Empowerment means that team members:
• Are given resources needed to perform their work.
• Make decisions that affect their work.
• Understand the limits to their authority and the escalation paths to
handle issues that transcend these limits.
• Are able, in turn, to rely on the integrity and motivation of other team
members to make and deliver on commitments.
! Emphasize that team activities are likely to involve many dependencies on
the work of other team members, and that in effective teams empowerment
leads to the development of their confidence that colleagues are committed
to the team’s objectives and empowered to achieve them.
! Build 2. Explain that MSF puts communication at the center of its team
model because it is critical to the team’s ability to work together to meet
project goals. Information that flows directly and freely to and from all team
members in a no-blame culture has many benefits:
• It reduces the chances of misunderstandings and wasted efforts.
• It helps to ensure that people have the information they need to make
decisions.
• It increases the team’s agility through the quick exposure of potential
problems.
• It promotes a learning environment in which people share what is and
isn’t working well, and thus it improves performance.
! Note that this philosophy represents a real departure from sharing
information on a “need-to-know” basis, which has been historically
characteristic of many organizations. Recall with students that they gained
some insights into the effectiveness of open communications in the activity
at the beginning of the module.

Module 2: Building an MSF Team xi

! Explain that MSF also advocates an open approach to communications with
external stakeholders for the following reasons:
• To better understand the business and user requirements of the solution.
• To enable the team to better manage stakeholder expectations as the
project proceeds so that there are “no surprises.”
• To keep stakeholders abreast of progress through project reports so they
can request changes or approve further efforts based on an accurate
understanding of progress to date and future plans.
Example: The following example illustrates both the empowered individuals
and open communications principles. It is a well-known Microsoft example
that occurred at the organizational level rather than the team role level; but it
applies in the same way. At the end of 1995, a small group of people within
Microsoft came to believe that the future of the company was linked to the
Internet. Although they represented a tiny number among the 17,000
employees, the company culture is one of empowerment, and they took the
step of presenting their arguments to Bill Gates. He listened, and in
December of that year, addressed a memo to the entire organization that
changed the direction of the company. Within 12 months, every Microsoft
product had at least minimal built-in Internet capability.
! Build 3. Explain that the last principle, “establish clear accountability,
shared responsibility,” takes us back to our original linking of roles with
responsibility for meeting project goals, and has both an external and an
internal face.
! Explain that clear accountability refers to the usual requirement by project
customers and/or sponsors to have a single, explicitly assigned point of
accountability for the ultimate success or failure of a project. Additionally,
other external stakeholders may request accountability with respect to
defined goals. It is important that the team clearly delineate within the
project structure those individuals who will fulfill these obligations to the
external accountability requirements. Typically, accountability to
stakeholders maps to the following roles:
• Product management is accountable to the customer (for the business
value of the solution).
• Program management is accountable to the project sponsor (for project
delivery).
• Release management is accountable to IT operations (for operability).
• User experience is accountable to user representatives (for usability).
! Explain that shared responsibility refers to the idea that team members share
equally in the responsibility for project success, because the work of each
role is essential to it. It also acknowledges the interdependencies in the
nature of the work—in reality, the work of one team role cannot be entirely
isolated from that of other team roles. And finally, it includes the notion that
decisions are made by the team that affect the work of each role and that
individual team members are encouraged to be aware of all perspectives and
take them into account when participating in team decision-making.
! Summarize by pointing out that the focus of accountability is to ensure that
external answerable commitments are fulfilled, while the focus of
responsibility is to ensure that internal tasks get successfully completed.

xii Module 2: Building an MSF Team

Key Concepts and Purpose
Proven Practices
To present key concepts and proven practices that are important to the team
model.

Delivery
! Explain that the concepts on the slide are descriptive of the MSF team
model, and highlight attitudes and values that are called for among
members. Describe them as follows:
• The team of peers concept defines a team as a group of clearly defined
roles, each owning a clearly defined goal that is necessary to the success
of the project. The roles are seen as peers with equal say in decisions.
This enables unrestricted communication between the roles, increases
team accountability, and reinforces the belief that each of the six quality
goals associated with the six roles is equally as important as the others
and must be achieved.

Note The team of peers is different from more traditional, hierarchical
teams in that there is no project manager role (students are likely to ask
about this). Project management is a function of the program management
role as well as a responsibility that is shared among the role team leads. This
will be discussed in detail later in the module.

• A customer-focused mindset means that team members are continually
mindful that satisfied customers are priority number one. Consequently,
everyone on the team commits to understanding and solving the
customer’s business problem.
• A product mindset is a matter of viewing one’s work as part of a project
that is aimed toward the delivery of a product, whether it is tangible or
intangible. This mindset is important because it gives meaning to the
work—it focuses on the real job of the team rather than the particular
tasks any one member might carry out. A product mindset can increase
motivation by giving teams a definite goal with which all members can
identify.
• A zero defect mindset represents a commitment on the part of every team
member to attain a predefined quality bar in their work throughout the
project. The concept should not be understood literally to mean no
defects, but the building of quality into the development process as
opposed to merely checking for it at the end.
• Willingness to learn is a prerequisite attitude for successful teams that is
related to the team of peers concept and the open communications
principle. It has several applications:
• Committing to self-improvement through gathering and sharing
knowledge
• Institutionalizing learning through such techniques as reviews and
postmortems
• Allowing team members to benefit from mistakes
• Helping team members to repeat successes
• Mandating time for the team to learn

Module 2: Building an MSF Team xiii

! Describe the three proven practices listed on the slide as follows:
• The use of small, interdisciplinary teams is a natural corollary of the
team of peers structure, with its definition of unique roles that require
different skill and knowledge sets. Small, interdisciplinary teams:
• Tend to be more agile than large teams.
• Have roles that are interdependent but specialized and focused on
their particular function.
• MSF advocates locating a team on one site when possible, for these
reasons:
• It eliminates obstacles to communication by allowing frequent
physical meetings and interactive exploration of ideas.
• It helps to enforce the sense of team identity and unity.

Note This does not preclude “virtual” teaming—it only makes it a
secondary rather than primary choice.

• All roles on the team participate in creating the functional specifications
for the solution because each role has a unique perspective of the design
and its relationship to their individual objectives, as well as the team’s
objectives.

Lesson Review Purpose
To reinforce the main points of the lesson by asking questions.

Delivery
Ask the following questions.
1. How are project goals, project success, and the MSF team model related?
Fundamental project goals must be equally valued and met. When these
goals are understood and met, this is an indication that typical barriers
to project success have been eliminated. The MSF team model
represents one way to assign responsibility for meeting all project goals.
2. What does the circular structure of the team model represent?
Nonhierarchical model—there is no project “boss.”
Inclusion—all team members see themselves within the solution space.
Interconnectedness and interlocking responsibilities of the role clusters.
3. Which of the eight MSF foundational principles are closely associated with
the team model?
Work towards a shared project vision. Focus on business value. Stay
agile, expect change. Empower team members. Foster open
communications. Establish clear accountability, shared responsibility.
4. What are some of the key concepts of the team model?
Team of peers. Customer-focused mindset. Product mindset. Zero
defect mindset. Willingness to learn.

xiv Module 2: Building an MSF Team

Lesson: MSF Team Role Clusters
MSF Team Role Clusters Purpose

Delivery
! Explain that this lesson focuses on MSF team role clusters, the functional
areas they represent, and the responsibilities associated with these areas.

MSF Team Role Clusters
Purpose
To explore further the concept of role clusters and prepare for discussion of
functional areas.

Delivery
! Explain that a role cluster defines a common way to identify a combined set
of functional areas and their associated responsibilities. The MSF team
model has defined six role clusters, each associated with a quality goal of
the solution.
! Explain that a role cluster may be one person or many team members,
depending on the size and complexity of the project, as well as the skills
required to fulfill the responsibilities of the functional areas.
! Explain that a functional area is a division of the role cluster into specific
activities. For example, the functional areas of the test role cluster are test
planning, test engineering, and test reporting. (Alert students that role
clusters and functional areas will be explored in more detail in the next
lesson.)
! Mention that tasking role clusters with goals that may be in tension with one
another is deliberate and provides important checks and balances on the
team. It accounts for the strength of the model in ensuring that decisions are
informed by all perspectives and that all viewpoints are represented.
! Explain that a subsequent lesson will show how roles may be combined, and
that some combinations have more risks than others, related to the loss of
healthy conflicts between the roles.

Optional
Ask the class if they can see areas of potential conflict between the roles, where
compromises will have to be made. They might suggest program management
and product management (budget/time vs. features).

Note Although the official wording is now role clusters—to distinguish the
fact that each role has multiple (or a cluster) of functional areas associated with
it—typically the word cluster is dropped and role clusters are referred to as
roles.

Module 2: Building an MSF Team xv

MSF Team Role Clusters Purpose
and Their Functional
To demonstrate that each role represents several related functional areas.
Areas
Delivery
! Point out that the range of activities required to fulfill the goals of each team
role means that the roles each represent several related functional areas.
! Elaborate by pointing out that the functional areas are conceptually related
in that they all serve the same goal but involve different responsibilities and
require different skill sets.

Note Do not go into detail about the functional areas at this time because,
following a slide showing the structure of role clusters, the next six slides
cover each role and its functional areas.

Structure of MSF Team Purpose
Role Clusters
To clarify the relationship of functional areas, responsibilities, and tasks within
role clusters.

Delivery
! Explain that each role contains several functional areas, and that associated
with each functional area are several responsibilities. These in turn contain
tasks, which describe the work at a detailed level.
! Help students to understand the structure by stepping through the example
as follows:
• Program management is the name of the role cluster.
• Project management and solution architecture are two of its functional
areas.
• Driving overall solution design and managing critical trade-off decisions
are two responsibilities associated with solution architecture.
• Identifying customer requirements and liaising with other project teams
on interoperability issues are two of the tasks that must be done in order
to drive the overall solution design.
! Explain to students that defining specific functional areas within each role is
helpful when it is necessary to divide the work of the role between two or
more persons.

xvi Module 2: Building an MSF Team

Program Management Purpose
Role Cluster
To further define the program management role by mapping the role’s primary
goal to its specific functional areas and responsibilities.

Delivery
Note This is the first of six slides that consider each role cluster and its
primary goals and functional areas in turn. Responsibilities belonging to each
functional area have been printed in the student notes. These details should be
referenced only to help students understand the role’s primary responsibilities
and how they are achieved. The slides should be delivered as interactively as
possible in order to maintain student interest despite the repetition.

! Focus on the key goal of program management (to deliver a solution within
project constraints) and touch on how each of the four functional areas
complement each other in support of this goal.
! Briefly explain each functional area and mention some of the
responsibilities listed in the student notes under these headings.
! Emphasize that many of the traditional responsibilities of project
management, such as the schedule, feature set, and project budget, fall to the
program manager, but this does not equate to the program manager having
sole responsibility for project management. Alert students that a lesson
focused on project management is upcoming.
! Note that process assurance is concerned with the quality of the process that
is being used by the team as a whole to deliver the solution. For example,
program management would determine the need to do risk management for
the project and assure that the risk management process was sufficient to
meet the goals of the project. This is different from quality control, which
looks at the outcome of the process (the solution), not the process itself.
! Mention that program management ensures that the project sponsor’s
expectations are understood and managed throughout the project.

Development Role Purpose
Cluster
To further define the development role by mapping the role’s primary goal to
its specific functional areas and responsibilities.

Delivery
! Focus on the key goal of development (to build according to specifications)
and touch on how each of the four functional areas complement each other
in support of this goal.
responsibilities listed in the student notes under these headings as necessary
to give students an understanding of the work of this role cluster.

Module 2: Building an MSF Team xvii

Test Role Cluster Purpose
To further define the test role by mapping its primary goal to its specific
functional areas and responsibilities.

Delivery
! Focus on the key goal of the test role (to approve for release only after all
solution quality issues are identified and addressed), explaining that
“addressing” all quality issues does not necessarily mean fixing all
defects—it can also mean providing a work-around solution and
documenting it.
! Touch on how each of the four functional areas complement each other in
support of the key goal.

Release Management
Role Cluster
Purpose
To further define the release management role through the mapping of the
role’s primary goal to its specific functional areas and responsibilities.

Delivery
! Focus on the key goal of release management (smooth deployment, ongoing
operations) and touch on how each of the five functional areas complement
each other in support of this goal.
! Mention that the release management role is key to facilitating direct
involvement of operations throughout the project life cycle.
! Identify to students the fact that this role cluster maps to the similar
Microsoft Operations Framework (MOF) release management role cluster,
and as such, acts as the liaison between MOF (operations) and MSF
(solutions development) teams.

User Experience Role
Cluster
Purpose
To further define the user experience role through the mapping of its primary

Delivery
! Focus on the key goal of user experience (to enhance user effectiveness) and
touch on how each of the six functional areas complement each other in
support of this goal.

xviii Module 2: Building an MSF Team

Product Management Purpose
Role Cluster
To further define the product management role by mapping the role’s primary

Delivery
! Focus on the key goal of the product management role cluster (to satisfy
customers) and touch on how each of the four primary functional areas
complement each other in support of this goal.
! Briefly mention some of the responsibilities that are listed in the student
notes under each functional area.

The Extended Project Purpose
Team
To explain how the team co-ordinates with external groups.

Delivery
! Explain that successful teams must interact, communicate, and coordinate
with other groups external to it, such as:
• Customers
• End users
• Other development teams
• Operations and support
• Sponsors
• Architects and steering committees
! Explain that program management, product management, user experience,
and release management are the primary facilitators, and note that the
graphic shows the external groups with which they work closely. These
roles are both internally and externally focused, whereas development and
test are internally focused and should be insulated from unnecessary
disruptions, especially during the latter phases of building and stabilizing
the solution.
! Emphasize that this graphic represents a high-level perspective. Teams
typically need to coordinate with many other external groups that are not
shown, such as quality assurance, finance, and legal departments or groups.
Interfaces with any such groups should be explicit and should be
communicated within the project structure document.
! Additionally, emphasize that while external coordination through the
various roles can provide input and recommendations, neither individual
members of the team nor the team as a whole have the authority to change
the priority or specifics of the project tradeoffs (such as features, schedule,
and resources). Those changes are the prerogative of the project customer or
sponsor and are implemented by the project team. This also provides an
example of how a team of equal partners or peers defers to and aligns with
organizational authorities, hierarchies, and structures.

Module 2: Building an MSF Team xix


Delivery
1. What is the definition of a role cluster?
A role cluster in the MSF team model is one of six groupings of
functional areas and their associated responsibilities. A role cluster may
be one person or many persons, depending on the size and complexity
of the project.
2. Is there a significant difference between the term “role cluster” and the term
“roles?”
No. The term “role clusters” is used to emphasize that each MSF role
has multiple (that is, a cluster) of functional areas associated with it.
For example, the product management role includes the functional
areas of business value, marketing, customer advocacy, and product
planning. However, practice has shown that role clusters can be
referred to as roles without a loss of understanding of the concept.
3. What are the three elements that distinguish the work of one MSF role
cluster from another role cluster?
The functional areas of the role cluster. The major responsibilities of
the role cluster. The work tasks of the role cluster.
4. Who are some of the external groups with which a successful team must
communicate?
Customers. End users. Other development teams. Operations and
support. Sponsors. Architects and steering committees. Quality
assurance. Financial. Legal.

xx Module 2: Building an MSF Team

Lesson: Scaling Teams for Project Efficiency
Lesson: Scaling Teams Purpose
for Project Efficiency

Delivery
! Explain that the previous lesson introduced the MSF team model roles and
their functions and responsibilities. This lesson focuses on how the
flexibility of the model and roles enables them to meet the needs of large
and complex as well as small projects and teams.

Ways to Scale Up Teams Purpose
To explain the reasons for and ways to scale up MSF teams.

Delivery
! Explain that complexity in a project may be related to:
• Size—features and/or team.
• Risks—higher risk may mean more resources to mitigate or greater skill
specialties required.
• Schedule—tight schedules may require more developers, testers, and so
on.
• Skills—outsourcing may be required to fulfill skill gaps.
! Describe what to do when team size increases, as follows:
• Divide the team into a core team and sub-teams.
• Have members of the core team function as team leads for the sub-team.
At this point the core team becomes known as the lead team. (Note that
this creates a hierarchical team structure but the structure is offset by
team leads being peer participants on core team.)

Module 2: Building an MSF Team xxi

Feature Teams Purpose
To introduce the concept of a feature team.

Delivery
! Explain that feature teams are sub-teams/projects that focus on building
specific features or capabilities of a solution. They may be organized around
a product feature set.
! Emphasize that feature teams are multidisciplinary. Explain that they
typically have the four roles of program management (PM), development
(dev), test, and user experience (UE) represented. Product and release
management are normally focused externally on customers and end-users,
and are thus not primary roles on feature teams.
! Ask students to notice that the team that is in the leadership position is
called the lead team. As the project scales up in size, the core team must
make a transition into a lead team, and take on lead team responsibilities.
Example: At Microsoft, the Microsoft Office team is a lead team, and the
applications teams such as Microsoft Word, Microsoft Excel, and Microsoft
Access are feature teams, each with their own program managers. The
Office team is responsible for such things as shared components and
compatibility of the applications.
! Explain that feature team members may be involved in more than one
feature team depending on requirements and complexity. Members:
• Could perform one role on one feature team and another role on a
different feature team.
• Could also be part of a function team (discussed next) while fulfilling a
role on a feature team.
! Note that the example shown in the slide is for an infrastructure project.
! Discuss with students an example of feature teams that might be formed for
an application development or Web services type project.

When to Use Feature Purpose
Teams
To explain when to implement feature teams.

Delivery
! Explain that feature teams should be formed whenever a situation requires
certain people to concentrate on a specific sub-set of the solution. This
occurs for various reasons—most often due to skills requirements, when a
larger problem is broken down into a series of smaller problems, or when
organizational or geographic boundaries create logistical constraints.
! Point out that using the right role combinations (discussed later) is an
important factor when forming feature teams.

xxii Module 2: Building an MSF Team

Function Teams Purpose
To introduce the concept of a function team.

Delivery
! Define the function team by reading the definition on the slide—a
unidisciplinary sub-team that is organized by functional role.
! Explain that as discussed in the previous lesson, a role cluster contains many
functions that require more than one person to fulfill that role when the
function is needed, particularly when complex projects are being staffed.
This scaling out of the role cluster to form function teams is usually a result
of project size or complexity.
! Explain that function teams may have an internal hierarchical reporting
structure.
! Use an example such as the following to explain why and how function
teams are formed.
Example: A large web development project that is fulfilling the role
requirements of UE:
• The skills and responsibilities required to fulfill the functions of user
interface design and those of internationalization can be quite different.
• Training/support material and usability research and testing functions
might be fulfilled by one individual but because the project is a large
scale project, require two people.
• A UE lead is assigned to coordinate the efforts of the entire role function
and to fulfill the project management duties at the function team level.
• Alternatively, the technical communications and the UE lead
responsibilities could be carried out by one person, and training/support
material fulfilled by another person if the project needed to use fewer
resources.
! Suggest that another possible combination is the release management role
which facilitates the operations and logistics functions, with the product
management role, for which the functional responsibilities include doing
customer requirements research, advocacy, and marketing.

When to Use Function
Teams
Purpose
To emphasize the common reasons for forming function teams.

Delivery
! Use this slide to re-emphasize the points from the last slide.
! Explain that individuals on function teams can also fulfill roles as needed on
other projects or sub-teams.
! Use the last bullet on the slide as a transition to the next slide, which
discusses the project management responsibilities of the team leads.

Module 2: Building an MSF Team xxiii

Team Leads on Large- Purpose
Scale Projects
To explain how team leads have project management responsibilities at the sub-
team level.

Delivery
! Explain that team leads have special requirements—to provide project
management services to the core team (that has become the lead team) by
taking on those responsibilities at the feature team level.
Example:
• Team leads facilitate cost and resource estimation for the sub-team and
provide this input to the core team, which “rolls up” the data.
• On behalf of their feature sub-team, team leads are responsible for
planning/tracking resources and skills/readiness.
• Team leads facilitate risk and quality management for the sub-team.
! Discuss the fact that this shared responsibility of project management is a
key differentiator of MSF compared to methodologies, which generally
prescribe a “top-down” approach. It is advantageous in that it:
• Allows task estimation to occur where it is generally most accurate—
with those who are actually doing the work.
• Streamlines communication.
• Keeps scope, cost, risk, quality, and other project management tasks a
shared responsibility so team members feel a greater sense of ownership
for success of their areas as well as the overall solution.
! Explain that as a project transitions through each phase there is a shift in the
primary role accountable for that phase. With this shift comes a heightened
responsibility for that role’s project management responsibilities. However,
the overall solution project management is still owned by program
management.
! Mention that more details on project management and MSF will be provided
in the next lesson.

MSF Sub-teams in Purpose
Relation to the Lead
Team To show how the concepts of feature and function teams relate to the lead team.

Delivery
! Explain that the program management role in feature teams is responsible to
be in close communication with the program management role in the lead
team.
! Explain that the role lead in a function team is the same person fulfilling
that role in the lead team.
! Discuss how feature and function teams relate and have the flexibility to
scale and be combined as needed.
! Remind students that within both feature and function teams, each member
may be serving additional responsibilities on various other teams or
projects.

xxiv Module 2: Building an MSF Team

Scaling Down— Purpose
Combining Roles for
To show the appropriate role combinations that help scale down an MSF team.
Smaller Teams
Delivery
Note This is a 4-build slide that shows first the blank chart, then the possible,
unlikely, and not recommended role combinations in turn.

! Build 1. Explain that the chart is set up like a mileage chart that shows the
distance between cities. The intersection of the rows and columns is where
to look to see if a particular combination is feasible.
! Builds 2-4. Click through the builds slowly enough for students to take in
which role combinations are possible, unlikely, and not recommended.
Explain that the use of Unlikely here means that finding an individual with
the appropriate skill sets to fulfill both roles effectively is difficult, thus
making the combination unlikely. The use of Not Recommended means that
although a choice can be made to combine these roles, as with the unlikely
combinations, there is a conflict in the required skills sets and even the goals
of these roles. Combining them could significantly impair project success.
! Explain through discussion with students how to scale down the team by
describing which combinations tend to work better and which are riskier
roles to combine. This is a good opportunity to ask students to apply their
understanding of the roles by suggesting some of the risks.
• Ask why combining program management and development would be
risky. If students don’t know, explain that it is never recommended to
combine the development role with other roles, for the following
reasons:
• Development should be focused only on building the solution, not
customer interaction or management tasks. Distractions during
building can cause slips in the delivery schedule due to the
dependencies typically involved with development deliverables.
• Combining development with other role responsibilities is generally
the most costly and riskiest—often leading to schedule slips.
• Ask what might be some of the risks of combining product management
and program management. If answers do not include this concept,
explain that certain roles, such as product management and program
management, should avoid being combined due to the conflicting focus
and goal for each role—for example, “satisfied customer” versus “ship
on time and within budget.”
• Ask what might be some of the risks of combining development and test.
Explain that developers cannot be expected to both build the entire
functionality of the solution and check their work for quality.
Additionally, the skills focus of the development and test roles are
typically different, thus making a combination of these two difficult.
! Emphasize that it’s not that teams can’t or must not combine roles—rather
that each combination generates risks that must be accounted for and
managed. Emphasize the importance of the fact that even if a combination is
risky, a greater risk is not having the role (and thus the associated goal for
that role) represented on the team.
! Explain that team members fulfilling multiple roles should make it clear
which role or roles they represent when they speak or offer guidance.

Module 2: Building an MSF Team xxv

Example: Small Teams Purpose
To provide an example of role combinations that have the least amount of risk.

Delivery
! Use the graphic to provide students with an example of possible role
combinations presented in the matrix.
! Note that these are not the only combinations, rather the ones that are
“okay” and present the least amount of additional risk.
! Highlight the fact that the development role here is still isolated to keep the
developers focused on building.
! Mention that the responsibilities of the test role in this scenario are typically
floating responsibilities.
• Coverage testing happens through the user experience (UE)/product
management (PdM)/test combined role.
• Usage testing, because it is validating the entire solution as a whole,
would then occur through the program manager/release manager
combination. Note that this is often a key point instructors miss when
delivering the material.
! Discuss with students other possible combinations that might work, making
sure to discuss their associated risks.
Example: program management and test, with a higher risk of quality bar
slipping to meet schedule/budget.

xxvi Module 2: Building an MSF Team


Delivery
1. Which role clusters are typically represented on feature teams? Why?
Program management, development, test, and user experience. Product
and release management are normally focused externally on customers
and so do not join feature teams.
2. What project situations call for the use of function teams?
When project tasks require more effort within a particular functional
area of a role than one person can perform. When the skill set required
for a role on the project is so diverse that it cannot be found in one
person.
3. How do team leads interact with sub-teams?
Team leads facilitate cost and resource estimation for a sub-team and
provide this input to the core team, which “rolls up” the data. Team
leads are responsible for planning and tracking resources, skills, and
readiness. Team leads also facilitate risk and quality management for
the sub-team.
4. Why is it a risk to combine some MSF roles? Which of the six MSF roles
should not be combined with any other roles?
The focus and goals of the roles may conflict with one another. The
required skill sets may be so different that it is unlikely, practically
speaking, to find individuals who possess all of the needed skills.
The development role should not be combined with other roles, because
this can lead to slips in the delivery schedule.

Module 2: Building an MSF Team xxvii

Lesson: A Scalable Approach to Project Management
Lesson: A Scalable Purpose
Approach to Project
Management To set expectations for student learning in this lesson.

Delivery
! Emphasize that this is not a primer on how to do project management. There
are numerous sources for this in the market. Explain that this lesson focuses
on how the MSF team model distributes project management
responsibilities in a way that maintains the balance of the team of peers.

The Project Management
Discipline
Purpose
To explain what project management is and why it is important, and to clarify
common misconceptions.

Delivery
! Explain that for many people, project management simply means “being the
boss” or “making all the important decisions.”
! Emphasize that, in MSF, project management is thought of as a discipline of
skills, tools, and techniques.
! Explain that the ownership, responsibility, and accountability for the project
are shared among the team leads of the project.
! Explain that teams at Microsoft are highly self-managed teams. On large
projects, the management team includes team leads representing each
feature team and the team leads representing centralized function teams.
Every lead in the team model shares project management responsibilities.
Team leads create, manage, and track their team plans, which are bundled
into the master plan for the project.

xxviii Module 2: Building an MSF Team

Project Management Purpose
Knowledge Areas
To describe the various knowledge areas involved in project management.

Delivery
Use the information in the following table (also provided to students in student
notes) to explain the project management knowledge areas.
Knowledge area Includes such activities as:

Project integration Integrating and synchronizing project plans
management Setting up procedures and systems to manage
Tracking change
Project scope management Defining and breaking down scope of work
Managing project tradeoffs
Project time management Generating and maintaining schedules
Task sequencing
Matching resources to tasks
Project cost management Preparing cost estimates
Progress reporting and analysis
Cost risk analysis
Value analysis
Project human resources Resource planning
management Team building
Conflict resolution
Skills readiness training
Project communications Communication planning
management Project status reporting
Project risk management Facilitating and driving team risk management
Maintaining risk documentation
Project procurement Soliciting contractor bids for services and/or
management hardware/software
Preparing requests for proposals (RFPs)
Managing vendors/subcontractors
Managing and negotiating contracts
Preparing purchase orders and approving invoices
Project quality Quality planning
management Determining standards
Documenting quality criteria and quality measurement
processes

Note These knowledge areas have been compiled by the Project Management
Institute (PMI).

Module 2: Building an MSF Team xxix

Distributing Project Purpose
Management on Large
To explain how the specific areas of project management are distributed in a
Projects
scaled-up MSF team.

Delivery
! Build 1. Tell the students that the matrix about to be shown clarifies how
the various team leads distribute the responsibility for project management.
Stress that it is important to clarify each team lead’s responsibilities in order
to avoid problems.
! Build 2. Direct the students’ attention to the list of team leads. Remind the
students that each lead is working with other individuals (not shown) in
their sub-teams.
! Build 3. Mention that these (slanted text entries at top of chart) are the
project management knowledge areas shown on the previous slide.
! Build 4. Explain that the MSF program management role cluster has project
management responsibilities for the project overall. These are denoted by
the solid dots.
! Build 5. Explain that each team lead has the project management
responsibilities denoted by the hollow dots for their sub-team.

Additional Notes
Program and release management might both share in overall procurement
responsibilities. This is because operations organizations already have
established vendors and purchasing procedures in place. Program management,
on the other hand, typically procures project resources (such as Web design,
testing services, and technical writing) and makes miscellaneous project
purchases. This helps the team to meet the goal of “delivery to constraints.”
Special Responsibilities
of Program Management
Purpose
To explain the special project management responsibilities of the program
management role cluster.

Delivery
! Explain that because the goal of the program management role cluster is
delivery of the solution to project constraints, project management is critical
to this role cluster. Point out that the terms “program management” and
project management sound similar. Remind the students of the difference—
otherwise the remainder of the lesson may be confusing. Program
management is an MSF role cluster, whereas project management is a set of
skills, techniques, and tools.
! Explain that larger projects may require dedicated full time expertise in
project management. In these cases, a function team may be created to fill
the program management role cluster.

xxx Module 2: Building an MSF Team

Background
The main idea here is that the design work, specifications writing, and
managing schedules, budgets, coordination, and so on becomes overwhelming
for one individual on larger projects. This problem is solved by a division of
labor for the program management role cluster. The solution architect focuses
100% on design and specifications while the project manager focuses entirely
on project management.
Scaling Up Project Purpose
Management Functions
To demonstrate the flexibility of the MSF team model to scale project
management responsibilities from small to large projects.

Delivery
! Build 1. Explain that in small teams, where the team roles are filled with
one person each or individuals are combining roles, the responsibilities of
the project management discipline all belong to the program management
role. Remind the students that this doesn’t mean that program management
is “the boss” or makes all the important decisions. Again, the
responsibilities are generally limited to the list of responsibilities listed in
the previous slides for the program management role.
! Build 2. Describe a larger scale scenario, where roles are filled by function
teams, each with a lead. Team leads, as well as program management, have
distributed project management responsibilities.
! Build 3. When project management duties alone require a full-time effort, a
dedicated project manager is needed. In this case, a program management
function team can be created that includes a project manager and a solution
architect.
! Build 4. (This build combines the views shown in builds 1–3.) Explain the
benefits of this approach to scaling project management responsibilities as
follows (benefits are also shown in the student notes).
• It is simple for small projects.
• It provides a project management structure for larger projects while
maintaining a balance among the team of peers.
• It provides flexibility for situations where a full-time specialist in project
management is needed.

Background
Note that in Builds 2 and 3, feature teams are not shown for simplicity. But the
same point applies with a combination of feature and/or function teams.
The emphasis here should be on flexibility. MSF team model provides many
possible combinations to provide the best structure for almost any type of IT
project.

Module 2: Building an MSF Team xxxi

Assessing Project Purpose
Management Complexity
To help students assess the project management risks on their projects and
gauge the level of project management readiness needed on their teams.

Delivery
! Explain the chart in the slide, which maps projects according to two
variables. The horizontal axis represents technical complexity, meaning
technical difficulty and risks. As projects move toward high end locations
on the axis, the team’s technical skill levels must also be higher to be
successful. The vertical axis represents project management difficulty and
risks. Again, as these increase, so must project management skill levels.
! Several factors for project management risk are shown in the list at the left
of the graphic. Elaborate on these factors and tie them back to project
management readiness. The key point here is that teams with great technical
skills, but lacking in project management skills, still face a risk of failure.
! Focus on Project A and Project B on the chart. The technical risks are the
same or similar, but project B faces additional project management risks.
Point out that the same project management skills and processes that were
sufficient for project A are likely to be insufficient in project B.
! Ask the students to provide examples from their experience of projects that
would fit the various quadrants. Ask them how project management was
conducted in those projects.


Delivery
1. What are some of the knowledge areas of project management?
Project integration management. Project scope management. Project
time management. Project cost management. Project communications
management. Project human resource management. Project
procurement management. Project risk management. Project quality
management.
2. “An MSF project manager should make all the important decisions.” True
or false?
False. In MSF, the project manager does not equate to “the boss.”
Project management is a discipline of skills, tools and techniques that
falls under the program management role for small teams and is shared
by all of the team leads for projects that require sub-teams. The entire
team shares ownership, responsibility, and accountability for the
project.

xxxii Module 2: Building an MSF Team

3. How do large, complex projects impose special requirements on the project
manager?
Large, complex projects may require dedicated, full-time expertise in
project management. They call for the creation of a function team to fill
the program management role, which typically includes a project
manager and a solution architect.
4. Which specific project risks map to complex project management
situations?
Large size or cost. Geographically dispersed project teams. Team
members spread across different companies, organizations or
subcontractors. Fixed or highly constrained budgets or schedules.

Summary
Module Summary
Purpose
To summarize the module.

Delivery
Review the main points on the slide.

Customization Information
There are no labs in this module, and as a result, there are no lab setup
requirements or configuration changes that affect replication or customization.

Lab Setup
There are no lab setup requirements that affect replication or customization.

Module 2: Building an MSF Team 1

Module Overview
! The MSF Team Model
! MSF Role Clusters
! Scaling Teams for Project Efficiency
! A Scalable Approach to Project Management

*****************************ILLEGAL FOR NON-TRAINER USE******************************
Introduction The MSF team model is based on many years of experience Microsoft® has in
forming small, multidisciplinary teams that successfully develop IT solutions.
Objectives After completing this module, you will be able to:
! Discuss how six of the eight MSF foundational principles apply to the team
model.
! Identify the major project goal associated with each team role cluster on an
MSF project.
! Identify how to organize an MSF team with a specific number of
participants.
! Discuss how project management in MSF is distributed among team leads
on large projects.

2 Module 2: Building an MSF Team

Lesson: The MSF Team Model
After completing this lesson, you will be able to:
! Describe why the MSF team model was created
! Describe the MSF team model structure
! Discuss the key concepts and proven practices that relate
to the team model
! Discuss how six of the eight MSF foundational principles
apply to the team model

Introduction This lesson introduces the MSF team model.
Lesson objectives After completing this lesson, you will be able to:
! Describe why the MSF team model was created.
! Describe the MSF team model structure.
! Discuss the key concepts and proven practices of the MSF team model.
! Describe how six of the eight MSF foundational principles apply to the team
model.


Activity: Communicating in Teams
Follow your instructor’s directions

The instructions for this activity are in the Activities Appendix. Your instructor
may have additional directions.

4 Module 2: Building an MSF Team

Symptoms of Challenged Projects
“The project
was late and “What was
over budget” built really
“It doesn’t meet isn’t what
our expectations – we needed”
“We didn’t
we’re not happy”
understand clearly
what we were
“We couldn’t get supposed to do”
the information “We were unaware
we needed to of how the work of
do our work” other team members
“We can’t get affected our work”
it to operate
“It’s just too
well in our “This thing is
difficult to use”
environment” unpredictable – we
keep discovering
new problems”

The quotes on the slide come from customers and project team members. Those
on the top and bottom represent typical complaints made by customers and
users when they are unhappy with the outcome of a project. The three
comments in the middle are from team members and offer some insight into the
obstacles they encountered in successfully completing their work.
Too often, the cause for project challenges or failures could have been
addressed by clearly identifying the main project goals and then modeling a
way to achieve those goals through designated participants on the team.
Microsoft has found that one of the best ways to reduce project failure rates is
by taking a proactive approach to organizing teams in a way that addresses
these common issues head-on.


Goals for Successful Projects
Typical Symptom Related Project Goal Goal
of Challenged Project for Success Ownership
“The project was late and over Deliver within project ?
budget” constraints
“What was built really isn’t what we Build to specifications ?
needed”
“This thing is unpredictable – we keep Release with issues identified ?
discovering new problems” and addressed
“We can’t get it to operate well in our Deploy smoothly and prepare ?
environment” well for ongoing operations
“It’s just too difficult to use” Enhance user effectiveness ?
“It doesn’t meet our expectations – Satisfy customers ?
we’re not happy”
“Needed information is not shared Establish good communications ?
timely to all who need it”

Microsoft has found that for a project to be successful, there are fundamental
goals that must be equally valued and met. When these goals are met, the
problems listed in the former slide have been resolved. Assigning responsibility
for meeting the goals marked the genesis of the team model.
! Satisfying customers. Projects must meet the needs of customers and users
in order to be successful. It is possible to meet budget and time goals but
still be unsuccessful if customer needs have not been met.
! Delivering the solution within project constraints. A key goal for all
teams is to deliver within project constraints. The fundamental constraints of
any project include those of budget and schedule. Most projects measure
success using “on time, on budget” metrics.
! Building to specification. The product specification describes in detail the
deliverables to be provided by the team to the customer. It is important for
the team to deliver in accordance with the specification as accurately as
possible because it represents an agreement between the team and the
customer about what will be built.
! Approving for release only after identifying and addressing all product
quality issues. All software is delivered with defects. A key goal is to
ensure that those defects are identified and addressed prior to releasing the
product. Addressing can involve everything from fixing the defect in
question to documenting work-around solutions. Delivering a known defect
that has been addressed along with a work-around solution is preferable to
delivering a product containing unidentified defects that may surprise the
team and customer later.

02.building a msf team

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 02.building a msf team

Similar a 02.building a msf team (20)

02.building a msf team