02.building a 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

Module 2: Building an MSF Team

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.

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

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.

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.

Required materials

Important

Preparation tasks

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.

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.

Purpose To announce the communicating-in-teams activity.

Delivery See activities delivery section in the instructor guide.

Purpose 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.

Lesson: MSF Team Model

Activity: Communicating in Teams

Symptoms of Challenged Projects

Module 2: Building an MSF Team v

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


! 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?�

Goals for Successful Projects

vi Module 2: Building an MSF Team

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.


! 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.

MSF Team Model

Module 2: Building an MSF Team vii

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.

Purpose 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.

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.

Note

Other Project Participants�External Stakeholders

Note

viii Module 2: Building an MSF Team

Purpose To explain how MSF foundational principles guide the functioning of the team.

Delivery

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.

This is a 3-build slide.

! 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.

MSF Foundational Principles Applied to Team Model

Note

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

Purpose To present the second group of foundational principles that guide the functioning of the team model.


! 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.

MSF Foundational Principles and Team Model (continued)

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

Purpose 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.

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

Key Concepts and Proven Practices

Note

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.

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.

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.

Note

Lesson Review

xiv Module 2: Building an MSF Team

Lesson: MSF Team Role Clusters This section describes the instructional methods for teaching this lesson.


Delivery ! Explain that this lesson focuses on MSF team role clusters, the functional

areas they represent, and the responsibilities associated with these areas. ! Read the objectives on the slide.

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).

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.

MSF Team Role Clusters


Note

Module 2: Building an MSF Team xv

Purpose To demonstrate that each role represents several related functional 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.

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.

Purpose 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.

MSF Team Role Clusters and Their Functional Areas

Note

Structure of MSF Team Role Clusters

xvi Module 2: Building an MSF Team

Purpose To further define the program management role by mapping the role�s primary goal to its specific functional areas and responsibilities.

Delivery

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.

Purpose 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.

! Briefly explain each functional area and mention some of the responsibilities listed in the student notes under these headings as necessary to give students an understanding of the work of this role cluster.

Program Management Role Cluster

Note

Development Role Cluster

Module 2: Building an MSF Team xvii

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.


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.

Purpose To further define the user experience role through the mapping of its primary goal to its specific functional areas and responsibilities.

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.


Test Role Cluster

Release Management Role Cluster

User Experience Role Cluster

xviii Module 2: Building an MSF Team

Purpose To further define the product management role by mapping the role�s primary goal to its specific functional areas and responsibilities.

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.

Purpose 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.

Product Management Role Cluster

The Extended Project Team

Module 2: Building an MSF Team xix



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.

Lesson Review

xx Module 2: Building an MSF Team

Lesson: Scaling Teams for Project Efficiency This section describes the instructional methods for teaching this lesson.


Delivery ! Read the objectives on the slide. ! 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.

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.)

Lesson: Scaling Teams for Project Efficiency

Ways to Scale Up Teams

Module 2: Building an MSF Team xxi

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.

Purpose 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.

Feature Teams

When to Use Feature Teams

xxii Module 2: Building an MSF Team

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.

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.

Function Teams

When to Use Function Teams

Module 2: Building an MSF Team xxiii

Purpose 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.

Purpose 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.

Team Leads on Large- Scale Projects

MSF Sub-teams in Relation to the Lead Team

xxiv Module 2: Building an MSF Team

Purpose To show the appropriate role combinations that help scale down an MSF team.

Delivery

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.

Scaling Down�Combining Roles for Smaller Teams

Note

Module 2: Building an MSF Team xxv

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.

Example: Small Teams

xxvi Module 2: Building an MSF Team



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.

Lesson Review

Module 2: Building an MSF Team xxvii

Lesson: A Scalable Approach to Project Management This section describes the instructional methods for teaching this lesson.


Delivery ! Read the objectives on the slide. ! 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.

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.

Lesson: A Scalable Approach to Project Management

The Project Management Discipline

xxviii Module 2: Building an MSF Team

Purpose 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 management

Integrating and synchronizing project plans

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 management

Resource planning

Team building

Conflict resolution

Skills readiness training

Project communications management

Communication planning

Project status reporting

Project risk management Facilitating and driving team risk management

Maintaining risk documentation

Project procurement management

Soliciting contractor bids for services and/or hardware/software

Preparing requests for proposals (RFPs)

Managing vendors/subcontractors

Managing and negotiating contracts

Preparing purchase orders and approving invoices

Project quality management

Quality planning

Determining standards

Documenting quality criteria and quality measurement processes

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

Project Management Knowledge Areas

Note

Module 2: Building an MSF Team xxix

Purpose To explain how the specific areas of project management are distributed in a scaled-up MSF team.


! 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.�

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.

Distributing Project Management on Large Projects

Special Responsibilities of Program Management

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.

Purpose To demonstrate the flexibility of the MSF team model to scale project management responsibilities from small to large projects.


! 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.

Scaling Up Project Management Functions

Module 2: Building an MSF Team xxxi

Purpose 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.



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.

Assessing Project Management Complexity

Lesson Review

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 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 Summary

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******************************

The MSF team model is based on many years of experience Microsoft® has in forming small, multidisciplinary teams that successfully develop IT solutions.

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.

Introduction

Objectives

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


This lesson introduces 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 of the MSF team model. ! Describe how six of the eight MSF foundational principles apply to the team

model.

Introduction

Lesson objectives


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.


Symptoms of Challenged Projects

�This thing isunpredictable � wekeep discoveringnew problems�

�It�s just too difficult to use�

�We couldn�t getthe informationwe needed to do our work�

�We were unawareof how the work of

other team membersaffected our work�

�The projectwas late andover budget�

�What was built really isn�t what

we needed��It doesn�t meet

our expectations �we�re not happy� �We didn�t

understand clearlywhat we were

supposed to do�

�We can�t get it to operate well in our

environment�


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

Establish good communications

Related Project Goal for Success

Deliver within project constraintsBuild to specifications

Release with issues identified and addressedDeploy smoothly and prepare well for ongoing operationsEnhance user effectiveness

�The project was late and over budget��What was built really isn�t what we needed��This thing is unpredictable � we keep discovering new problems��We can�t get it to operate well in our environment��It�s just too difficult to use�

Typical Symptomof Challenged Project

Satisfy customers

Goal Ownership

�It doesn�t meet our expectations �we�re not happy�

?

?

?

?

?

?

�Needed information is not shared 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.


! Enhancing user effectiveness. In order for a product to be successful, it must enhance the way that users work and perform. Delivering a product that is rich in features and content but is not usable by its designated users is considered a failure.

! Smooth deployment and ongoing operations. Sometimes the need for a smooth deployment is overlooked. For example, a poor deployment may lead users to assume that the solution itself is similarly faulty, even when this may not be true. Consequently, the team must do more than just deploy; it must strive for a smooth deployment. It also must prepare for the support and management of the product by IT operations. This can include ensuring that training, infrastructure, and support are in place prior to deployment.


MSF Team Model

Communication

Delivering the solution within project constraints

Satisfied customers

Enhanced user effectiveness

Smooth deployment and ongoing operations

Approval for release only after all quality issues are identified and addressed

Building to specification

DevelopmentDevelopment

TestTest

ReleaseManagement

ReleaseManagement

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management


The MSF team model is a model for IT project teams. It has six role clusters (commonly referred to as just �roles�) that correspond to major project goals and have responsibility for them.

The circular structure of the model, with equally sized ovals for the roles, shows that it is a nonhierarchical model and that each role is considered equally important in its contribution to the project. Although different roles may be more or less active at different stages of a project, none can be omitted.

The placement of communication in the center of the circle connotes that it is integral to the structure. Effective communication is supported by the model and is essential to its functioning.


Other Project Participants � External Stakeholders

! Project sponsors � Individuals who initiate and approve a project and its result

! Customers (also known as business sponsors) �Individuals who expect to gain business value from the solution

! End users � Individuals or systems that directly interact with the solution

! Operations � The organization responsible for ongoing operation of the solution after delivery


The team needs to identify and build relationships with the individuals and groups defined below. Particular roles tend to relate to particular parties external to the team.

Term Definition External stakeholder Individual or group that has an interest or �stake� in the

outcome of a project

Project sponsor Individual who initiates and approves a project and its result

Customer Individual who expects to gain business value from the solution (also known as business sponsor)

End user Individual or system that directly interacts with, or uses, the solution

Operations The IT organization responsible for ongoing operation of the solution after it has been delivered

Definition


MSF Foundational Principles Applied to Team Model

Work toward a shared visionFocus on business valueStay agile, expect change


A shared vision for the project is fundamental to the work of the team. The process of creating that vision helps to clarify goals and bring conflicts and mistaken assumptions to light so they can be resolved. Once agreed upon, the vision motivates the team and helps to ensure that all efforts are aligned in service of the project goal. It also provides a way to measure success.

Maintaining a focus on business value is important because providing business value is IT�s most basic mandate. Keeping this business reality and the specific business goal of the project clearly in mind helps the team in making tradeoff decisions about features of the solution or other aspects of the project, if they become necessary.

A team that is mentally prepared for change and has the agility to be able to capitalize on opportunities and sidestep potential problems has greatly improved chances for success. Even the most carefully planned projects are subject to change, which can come from a number of different sources, such as business pressures and technology developments.


MSF Foundational Principles and Team Model (continued)

Empower team membersFoster open communicationsEstablish clear accountability, shared responsibility


Empowering team members means giving them the resources and the authority to fulfill the responsibilities associated with their roles. It not only helps individuals to do their work, but leads to the ability to rely on fellow team members to make and deliver on their commitments.

Communication is at the center of the MSF team model because it is critical to the team�s ability to work together to meet project goals. Communication problems, leading to lack of understanding or awareness, are frequently cited as a root cause of project failures; the MSF team model is specifically structured to eliminate the communications barriers that exist in more hierarchical team structures. Open communications means two-way communications�telling and listening. MSF advocates fostering open communications both within the team and externally with stakeholders.

The principle of �clear accountability, shared responsibility� has both an internal and an external face. Internally, the team shares responsibility equally for the success of the project in recognition of the idea that a project cannot be considered successful if any one of its goals is not met. 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.


Key Concepts and Proven Practices

! Key concepts" Team of peers" Customer-focused mindset" Product mindset" Zero defect mindset" Willingness to learn

! Proven practices" Use small, interdisciplinary teams" Enable teams to work together at a single site" Create a solution design through total team participation


The team of peers concept views 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 team is nonhierarchical. MSF has found that certain mental attitudes, or �mindsets,� are key to its functioning. They follow.

A customer-focused mindset means that team members are continually mindful that satisfied customers are priority number one. This concept is closely related to the principle of maintaining a focus on business value, because customers are the ones who receive the business value.

A product mindset represents an approach to work. Viewing one�s work as part of a project that is aimed toward the delivery of a product, whether it is tangible or intangible, helps team members to understand the meaning of the particular task they are carrying out in the context of the real goal of the team.

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. It does not mean literally no defects. It means building quality into the work during the course of the project as opposed to merely checking it for at the end.

Willingness to learn is another prerequisite attitude for optimal functioning of the team. It supports learning new skills and knowledge that are necessary for the work, learning what works in order to repeat successes, and learning from mistakes in order to avoid repeating them. It helps teams to break away from old ways of doing things with its tolerance for mistakes as part of the cost of progress. It is closely related to the principle, �stay agile, expect change.�


MSF has adopted three practices that have been proved effective in enhancing teams� success rates in delivering solutions. The first, to use small, interdisciplinary teams, forms part of the definition of an MSF team. The reasons that these teams are successful are closely related to the communications and agility principles. Working together at a common site is another way of eliminating communications barriers and building up a sense of team identity and unity. Total participation in solution design ensures that the solution has input from all major perspectives and reinforces the sense of responsibility that each team member has for the solution.


Lesson Review

1. How are project goals, project success, and the MSF team model related?

2. What does the circular structure of the team model represent?

3. Which of the eight MSF foundational principles are closely associated with the team model?

4. What are some of the key concepts of the team model?


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 as an integral part of the solution. 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.

Now is the time to ask any further questions you might have about the material presented in this lesson.


Lesson: MSF Role Clusters

After completing this lesson, you will be able to:! List the MSF team role clusters! Describe the structure of MSF team role clusters! Recognize the major functional areas that belong to each

role cluster! Describe communication between the project team and

external groups! Identify the major project goal associated with each team

role cluster on an MSF project


This lesson describes the MSF role clusters.


! List the MSF team role clusters. ! Describe the structure of MSF team role clusters. ! Recognize the major functional areas that belong to each role cluster. ! Describe communication between the project team and external groups. ! Identify the major project goal that is associated with each team role cluster

on an MSF project.

Introduction

Lesson objectives




TestTest

ReleaseManagement

ReleaseManagement

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management

Communication


An MSF team role cluster identifies a set of related functional areas and the responsibilities that are associated with these areas. Each role cluster contains from three to six areas that are each necessary to support its quality goal. The functional areas often but not always require similar skill sets. The responsibilities defined for each area need to be carried out in order to meet the quality goal for the solution.

Example: The test role cluster contains three functional areas�test planning, test engineering, and test reporting. One of the responsibilities of test planning is to develop test specifications. This must be done in order to meet the quality goal of the test role cluster, which is to approve a solution for release only after all solution quality issues are identified and addressed.

One person or several may fulfill the responsibilities of a role cluster, depending on the size and complexity of a project and the skills it requires. In some cases, one person may fill more than one role. (The term �role cluster� is often shortened to �role.�)

Role clusters are deliberately tasked with responsibilities that are in conflict with one another to build in checks and balances and to ensure that all perspectives are represented in team decisions. The most obvious example of this is product management, which may advocate for additional features (requiring more time and resources), and program management, which seeks to complete the project within time and budget constraints.

Term Description Role cluster In the MSF team model, one of six groupings of functional areas

and their associated responsibilities that all support a quality goal for a solution. One or many persons may fulfill the responsibilities of the role cluster, or role (as it is commonly termed).

Definition


MSF Team Role Clusters and Their Functional Areas

Business valueMarketingCustomer advocacyProduct planning

Project managementSolution architectureProcess assuranceAdministrative services

Technology consultingImplementation architecture

and designApplication developmentInfrastructure development

Test planningTest engineeringTest reporting

InfrastructureSupportOperationsLogisticsCommercial release

management

AccessibilityInternationalizationUser advocacyTraining/support materialUsability research and testingUser interface design


TestTest

ReleaseManagement

ReleaseManagement

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management


Each role contains several closely related functional areas that support the goal of the role.


Structure of MSF Team Role Clusters

Example

Role cluster (role)Functional areas

Responsibilities

Tasks

Program managementProject management

Drive overall solutiondesign

Manage functionalspecification

Maintain traceabilitymap

Liaise with otherproject teams oninteroperabilityissues

Solution architecture


The work of the roles in the MSF team model is structured as follows:

! Each of the six roles contains several functional areas. ! Each functional area has several major responsibilities associated with it. ! In turn, each responsibility can be broken down into the tasks required to

carry it out.

When the work belonging to a particular role on any project becomes too much to be handled by one person, the functional areas offer guidance in dividing the responsibilities between two or more persons.


Program Management Role Cluster

! Goal: To deliver solution within project constraints ! Functional areas

" Project management" Solution architecture" Process assurance" Administrative services


The key goal of the program management role cluster is to deliver the solution within project constraints. Four functional areas support this goal. They are listed along with their associated responsibilities as follows:

Project management

! Tracking and managing the budget and the master project schedule ! Driving the risk management process ! Managing resource allocation and facilitating communication within the

team ! Tracking progress and managing status reporting

Solution architecture

! Driving overall solution design, and managing the functional specification ! Managing the solution scope and critical trade-off decisions

Process assurance

! Driving process quality assurance, and defining and recommending improvements

Administrative services

! Implementing processes and supporting team leads in using them


Development Role Cluster

! Goal: To build according to specifications! Functional areas

" Technology consulting" Implementation architecture and design" Application development" Infrastructure development


The development role uses the solution architecture, the solution designs, and the function specification to create the solution.

Its key goal is to build the solution according to these specifications. Four functional areas support this goal. They are listed along with their associated responsibilities as follows:

Technology consulting

! Serving as technology consultant; evaluating and validating technologies ! Participating actively in creating and reviewing the functional specification

Implementation architecture and design

! Mapping enterprise architecture to solution�s implementation architecture ! Owning and implementing physical designs of the solution

Application development

! Coding features to meet design specifications ! Conducting code reviews; conducting unit testing with test role support

Infrastructure development

! Developing features that meet design specifications ! Developing deployment documentation; scripts for automated deployment ! Conducting code reviews; carrying out unit testing with support from test


Test Role Cluster

! Goal: To approve for release only after all solution quality issues are identified and addressed

! Functional areas" Test planning" Test engineering" Test reporting


All software is delivered with defects. The key goal of the test role cluster is to approve a solution for release only after all quality issues are identified and addressed. �Addressing� can mean fixing the defect in question or documenting work-around solutions.

Three functional areas support this goal. They are listed along with their associated responsibilities as follows:

Test planning

! Developing a testing approach and plan ! Participating in setting the quality bar ! Developing test specifications

Test engineering

! Developing and maintaining automated test cases, tools, and scripts ! Conducting tests to accurately determine status of solution development ! Managing the build process

Test reporting

! Providing the team with product quality data ! Tracking all bugs and communicating issues to ensure their resolution

before release


Release Management Role Cluster

! Goal: To achieve smooth deployment, ongoing operations ! Functional areas

" Infrastructure" Support" Operations" Logistics" Commercial release management


The key goal of the release management role cluster is smooth deployment and ongoing operations. Five functional areas support this goal. They are listed along with their associated responsibilities as follows:

Infrastructure

! Developing enterprise infrastructure planning, and policies and procedures ! Coordinating physical environment use and planning across geographies ! Managing hardware/software procurement ! Building test and staging environments that accurately reflect production

Support

! Providing primary liaison and customer service to IT users ! Managing service level agreements with customer ! Providing incident and problem resolution

Operations

! Managing account, system setup controls; messaging, database, and so on

Logistics

! Providing duties of logistics management to the team

Commercial release management

! Managing all aspects of getting the product into the channel


User Experience Role Cluster

! Goal: To enhance user effectiveness ! Functional areas

" Accessibility" Internationalization" User advocacy" Training/support material" Usability research and testing" User interface design


The key goal of the user experience role cluster is to enhance the effectiveness of the solution for users. Six functional areas support this goal. They are listed along with their associated responsibilities as follows:

Accessibility

! Driving accessibility concepts and requirements into design

Internationalization

! Improving the quality and usability of the solution in international markets

User advocacy

! Acting as user advocate to the project team

Training/support material

! Developing and executing learning strategies ! Designing and developing support system and help documentation

Usability

! Gathering, analyzing, and prioritizing user requirements; developing usage scenarios, use cases; providing feedback on solution design

User interface design

! Driving user interface design


Product Management Role Cluster

! Goal: To satisfy customers ! Functional areas

" Business value" Marketing" Customer advocacy" Product planning


The product management role cluster focuses on customers and customer satisfaction. Note that it is very important that the customer for each project be clearly identified and understood (the project customer requesting a particular feature may not be the project sponsor).

Four functional areas support this goal. They are listed along with their associated responsibilities as follows:

Business value

! Defining and maintaining business justification for the project ! Defining and measuring the business value realization and metrics

Marketing

! Driving marketing and PR messages

Customer advocacy

! Driving a shared project and solution vision, while managing customer expectations and communications

Product planning

! Gathering, analyzing, and prioritizing customer and business requirements ! Determining business metrics and success criteria ! Identifying multi-version release plans


The Extended Project Team

Operationsand

SupportGroups

Technology Focus

Business FocusUsers

Project Sponsor

Customer

Technology Architects and Steering Committees

Help Desk

Project Team

UserExperience

Development

Test

ReleaseManagement

ProductManagement

ProgramManagement


Successful teams must interact, communicate, and coordinate with other external groups, ranging from customers and end users to other product development teams.

The graphic shows the primary external groups with whom each of the program management, product management, release management, and user experience interact. The team�s development and testing roles are insulated from external communications. They must be insulated because they�re the builders and doers and because distracting them would interfere with shipping on schedule.


Lesson Review

1. What is the definition of a role cluster?2. Is there a significant difference between the terms �role

cluster� and �role?�3. What are the three elements that distinguish the work of

one MSF role cluster from another role cluster?4. Who are some of the external groups with which a

successful team must communicate?


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.



Lesson: Scaling Teams for Project Efficiency

After completing this lesson, you will be able to:! Describe the purposes of feature and function teams! Discuss the MSF approach to scaling the team model! Discuss team leads, their purpose, and their function! Describe the risks associated with combining roles! Identify how to organize an MSF team with a specific

number of participants


The previous lesson introduced the six roles of the MSF team model. In this lesson, the focus is on the flexibility of the model, which enables it to be scaled to meet the needs of any project.


! Describe the purposes of feature and function teams. ! Discuss the MSF approach to scaling the team model. ! Discuss team leads, their purpose, and their function. ! Describe the risks associated with combining roles. ! Identify how to organize an MSF team with a specific number of

participants.

Introduction

Lesson objectives


Ways to Scale Up Teams

! Use factors such as complexity, size, risk, and skills for scaling

! Divide large teams into smaller teams, which have lower process, management, and communication overhead and allow faster implementation

! Designate team leads for sub-teams! Use core team to manage overall project

" Core team is composed of team leads and program management" Core team coordinates and synchronizes sub-teams


Some projects are either too large or too complex to be handled by a core team in which each role is fulfilled by one individual. The MSF team model accommodates the need for scalability through the notion of sub-teams, which are additional teams that are created to handle a volume of work or types of work that the core team cannot accomplish in the time that is available. Control and communication are maintained by having the members of the core team function as team leads for the sub-teams.


Feature Teams Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement

ProductManagement

ProductManagement

UserExperience

UserExperience


TestTest

Lead Team

DesktopFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

File and Print FeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

MessagingFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest


One way in which feature teams are different from function teams (to be discussed next) is that they are multidisciplinary. They usually contain all of the roles that have a strong internal focus as part of their responsibilities�that is, all but product management and release management, which are more externally focused. A second difference is that the program management role is not usually filled by a member of the lead team.

The slide shows an example of feature teams for an infrastructure project.

Term Definition Feature team Multidisciplinary sub-team that is created to focus on building

specific features or capabilities of a solution

Definition


When to Use Feature Teams

Consider using feature teams when:! The solution has highly independent components! Members are very dispersed across organizations or

geography! There is a need to fit skills (through outsourcing, for

example) or organizational boundaries


Feature teams are generally used in situations that call for a group to focus on a specific sub-set of the solution. Typical situations are:

! The solution is one that permits components to be worked on independently. ! Team members are dispersed across geographical or organizational

boundaries, which causes logistical constraints in terms of meeting and working together.

! The solution requires additional skill sets not possessed by the core team.


Function Teams Unidisciplinary sub-teams organized by functional role

Team lead

Usability research and

testing

Training/support material

Internationalization User advocacy

User Experience

User interface design

Accessibility


Function teams are used to fulfill just one role (they are unidisciplinary), but several functional areas within that role. Many roles encompass functional areas that are different enough so that they might be difficult for one person to fulfill, depending on the requirements of the project.

The team lead on the function team is assigned the project management responsibilities at the function team level.


When to Use Function Teams

Consider using function teams when:" Project tasks require a larger team effort to fulfill one or more

functional areas within a single role cluster" Project tasks require a more diversified effort to fulfill the

functional areas within a single role cluster


A function team is formed when more than one person is needed to fulfill the functional areas associated with a role. This may be the case because there is too much work for one person. In other situations, the work that must be done requires a diverse set of skills that cannot be found in one person.


Team Leads on Large-Scale Projects

! Feature team leads have project management responsibilities for their sub-teams

! Leads provide direct input to program management for overall project planning and scheduling

! The project management focus transitions across roles throughout the life of the project


When projects require feature teams, the team leads for those teams take on the responsibilities of project management at the feature team level. These responsibilities include such items as estimating costs and resources, and planning for and tracking the resources that will be needed as well as the state of readiness of the team members.

Shared responsibility for project management represents a key differentiator of MSF when it is compared to many methodologies, which commonly use a �top-down� approach. The MSF approach has these advantages:

! Tasks are estimated by those who understand them best�the people who carry them out.

! Communication is streamlined. ! Scope, cost, risk, quality, and other project management tasks are

maintained as a shared responsibility so team members feel a greater sense of ownership for success of their areas as well as the overall solution.

In different phases of the project, different roles are primarily accountable for the work of the phase. Likewise, team leads will be busiest with project management responsibilities when their role is focused upon for a particular phase. Nonetheless, the program manager still �owns� the responsibility for the overall solution project management.


MSF Sub-teams in Relation to the Lead Team

Function team

Feature teams

Lead teamProgram

ManagementProgram

Management

ReleaseManagement

ReleaseManagement

ProductManagement

ProductManagement

UserExperience

UserExperience


TestTest

DesktopFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

File and PrintFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

MessagingFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

UserExperience

Role Lead


Both function and feature teams work under the leadership of the core team. The core team will have made the transition to being a lead team when feature and function teams are needed on a project. Core team members are often the team leads on the function teams. In feature teams, the team lead is in close communication with and takes direction from the core team member.


Scaling Down � Combining Roles for Smaller Teams Roles may be combined, but some combinations pose risks

NN N

N

N

NNN

N

N N NPP

PPP

P

P

P

P

PU

U

UU

U U

U

U

P Possible U Unlikely N Not Recommended

ProductManagement

ProductManagement

ProgramManagement

ProgramManagement DevelopmentDevelopment TestTest User

ExperienceUser

ExperienceRelease

ManagementRelease

Management

ProductManagement

ProductManagement

ProgramManagement

ProgramManagement


TestTest

UserExperience

UserExperience

ReleaseManagement

ReleaseManagement


It is clear that the goals of the roles have varying levels of conflict. These tensions both make the team model dynamic and in turn increase the possibility of problems when trying to combine roles. Role combinations are not uncommon�and if the team chooses smart combinations and actively manages the associated risks, the problems that occur should be minimal.

Successful role sharing comes down to the actual team members themselves and the experience and skills they bring with them.


Example: Small Teams

UserExperience

UserExperience

ProductManagement

ProductManagement

TestTest

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement


Small team, combined roles


This example shows one permutation of the possibilities of combining roles for a small project team. This three person team consists of two people taking on multiple roles that when merged have the lowest amount of risk associated with their combination; as well as keeping the individual with the development role isolated from additional roles.


Lesson Review

1. Which role clusters are typically represented on feature teams?

2. What project situations call for the use of function teams?3. How do team leads interact with sub-teams? 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?


1. Which role clusters are typically represented on feature teams? 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 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? Skill sets may conflict across role clusters, and cause even larger and more significant conflicts in the goals of each of the role clusters. The development role should not be combined with other roles, as this can lead to slips in the delivery schedule.



Lesson: A Scalable Approach to Project Management

After completing this lesson, you will be able to:! Describe the project management discipline! Describe the special project management responsibilities of

the program management role cluster ! Discuss how project management in MSF is distributed

among team leads on large projects


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.


! Describe the project management discipline. ! Describe the special project management responsibilities of the program

management role cluster. ! Discuss how project management in MSF is distributed among team leads

on large projects.

Introduction

Lesson objectives


The Project Management Discipline

�Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements� (Project Management Institute)! Does not equate to �being the boss�! Is especially critical for scaled-up project teams


MSF draws a distinction between the authority of a project, or �who is in charge,� and the discipline of project management.

Project management in MSF is a discipline of knowledge, skills, tools, and techniques. Various members on a team may have project management responsibilities.

The ownership, responsibility, and accountability for the project are shared among the team leads of the project.

The definition of project management given in the slide on this page is from the Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) � 2000 Edition, Project Management Institute, Inc., 2000. All rights reserved.


Project Management Knowledge Areas

Project management includes these knowledge areas*:! Project integration management! Project scope management! Project time management! Project cost management! Project human resource management! Project communications management! Project risk management! Project procurement management! Project quality management


For each knowledge area∗, activities that an MSF project might require are listed below.

Knowledge area Includes such activities as: Project integration management

Integrating and synchronizing project plans

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 resource management

Resource planning

Team building

Conflict resolution

Skills readiness training

Project communications management

Communication planning

Project status reporting

*Source: Knowledge areas from Project Management Institute.


(continued) Knowledge area Includes such activities as: Project risk management Facilitating and driving team risk management

Maintaining risk documentation

Project procurement management

Soliciting contractor bids for services and/or hardware/software

Preparing requests for proposals (RFPs)

Managing vendors/subcontractors

Managing and negotiating contracts

Preparing purchase orders and approving invoices

Project quality management Quality planning

Determining standards

Documenting quality criteria and quality measurement processes


Distributing Project Management on Large Projects

Team leads for each role own the responsibilities corresponding to the listed knowledge areas

Release ManagementUser Experience

TestDevelopment

Product ManagementProgram Management

Team Leads Quality Management

Procurement Management

Risk Management

Communications Management

Human Resource Management

Cost Management

Time Management

Scope Management

Integration Management

at overall project level at sub-team level


This matrix clarifies each team lead�s project management responsibilities.

! Program management role cluster conducts project management at the overall project level.

! Team leads conduct project management at the sub-team level for the sub-teams they lead.

Certain responsibilities corresponding to three of the listed knowledge areas* in the graphic require special explanation.

! Cost management�Because project budget tracking is most efficient if it is done centrally, program management conducts this for all parts of the project. It doesn�t make sense for leads to track costs at the sub-team level, although they fulfill other responsibilities related to cost management such as preparing cost estimates.

! Communications management�Both product and program management role clusters coordinate project communications for the project as a whole.

! Procurement management�The release management role cluster, as a representative of IT operations, often has the responsibility to procure hardware and software on behalf of the project. Program management typically procures project resources and makes miscellaneous purchases.


Example: On a large team, the test lead gathers estimates from the rest of the test team (sub-team) for inclusion into overall cost and schedule estimates. With ample input from the test team, the test lead is the point person for creating the test plan, tracking testing tasks, determining work assignments of various testers, identifying testing-related risks, communicating test data and status of the test team, and acting as formal spokesperson for the test team. The test lead also identifies the quality standards and best practices for the testing process, documenting procedures and ensuring that they are being followed.

The test lead meets weekly with the other leads on the core team to review overall project progress. She also meets with the test team at least once a week to discuss testing issues.

The program manager for the same team has a similar set of responsibilities; however these are at the overall project level. The program manager gathers estimates from the other team leads and prepares the cost and schedule estimates. With input from the team leads (a team of peers) the program manager integrates the various plans into a master plan, synchronizes the schedules, consolidates all the risks into a project risk document, communicates project status on behalf of the whole team each week, and is the main point of contact for specific project-related issues. The program manager also notes the quality standards and procedures used by the other roles and follows up with the appropriate team leads if they are not followed.

*Source: Knowledge areas in graphic from Project Management Institute.


Special Responsibilities of Program Management

! Project management is an especially important competency of the program management role cluster

! Some large, complex projects require specialist project managers

Solution Architect

Example of function team for program management

Project Manager

Program Management

Program Management


The program management role cluster must have especially good project management skills to deliver the solution within its constraints of resources, budget, and schedule.

Some larger, more complex projects need a team member who is dedicated exclusively to project management. In these cases the program management role cluster is filled with a function team that includes a project manager and a solution architect.


Scaling Up Project Management Functions When project management becomes complex��program management function team includes solution architect and project manager

!

Development

Test

ReleaseManagement

UserExperience

ProductManagement

Program Management

Program Management

When roles are filled by subteams, each with a team lead��project management is distributed among team leads

"

Development

Test

ReleaseManagement

UserExperience

ProductManagement

Program Management

Program Management

When all team roles are filled by six persons or less��program management ownsproject management activities

#

Development

Test

ReleaseManagement

UserExperience

ProductManagement

Program Management

Program Management

At three levels of scale��who is participating in project management?

When project management becomes complex�!

When roles are filled by subteams, each with a team lead�"

When all team roles are filled by six persons or less�#

� program management ownsproject management activities

� project management is distributed among team leads

� program management function team includes solution architect and project manager

ProgramManagement

ProgramManagement

Development

Test

ReleaseManagement

UserExperience

ProductManagement

ProgramManagement

ProgramManagement

Development

Test

ReleaseManagement

UserExperience

ProductManagement

ProgramManagement

ProgramManagement

Development

Test

ReleaseManagement

UserExperience

ProductManagement


The graphic above represents who is involved in project management in small projects and in larger, more complex projects.

! In scenario 1, the program management role cluster is responsible for project management activities. In other words, things like managing schedule, scope, cost, risk, and so on belong to this role. This does not mean that these things are dictated without proper participation and input from the other roles.

! Scenario 2 represents a larger project with sub-teams and team leads. Program management conducts project management at the overall project level. Team leads have similar project management responsibilities, only at the sub-team level.

! In scenario 3, the project has a high level of management complexity. Keeping up with the design and specifications work plus the project management tasks requires a division of labor. A solution architect focuses on design and specifications while a project manager focuses exclusively on project management. These two individuals together fill the program management role.

Benefits of this approach include:

! 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.


Assessing Project Management Complexity

" Large size or cost

" Geographically dispersed

" Multiple organizations

" Contractual, legal issues

" Fixed budgets, schedules

! What are your project management risks?

Project B

Low

Technical ComplexityPr

ojec

t Man

agem

ent C

ompl

exity

Hig

h

Low High

Project A

Project C

Project D

Project E


Projects with these risks have high project management complexity:

! Large size or cost ! Geographically dispersed teams ! Team members belonging to multiple companies, organizations or

subcontractors ! Fixed or highly constrained budgets or schedules ! Contractual or legal issues that require skills, time, or energy

The specific risk thresholds depend on the project or organization. Be sure that your team�s project management readiness is commensurate with the level of risk.


Lesson Review

1. What are some of the knowledge areas of project management?

2. �An MSF project manager should make all the important decisions.� True or false?

3. How do large, complex projects impose special requirements on the project manager?

4. Which specific project risks map to complex project management situations?


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.


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.

Now is the time to ask any questions you may have about the topics presented in this lesson.


Module Summary

! Six quality goals drive the team and define the team model

! Effective teams " Are constituted as teams of peers" Are not built around an organizational chart" Foster open communications" Are based on small, multidisciplinary teams

! MSF teams can be scaled up or down depending on need! A project management discipline

" Enables a team of peers to work better" Enables better scaling up of the team model


Now is the time to ask any questions you may have about the topics presented in this module.

THIS PAGE INTENTIONALLY LEFT BLANK

02.building a msf team

Documents

Transcript of 02.building a msf team