02.building a msf team


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

02.building a msf team

  1. 1. Module 2: Building an MSF TeamContentsModule Overview 1Lesson: The MSF Team Model 2Lesson: MSF Role Clusters 15Lesson: Scaling Teams for ProjectEfficiency 28Lesson: A Scalable Approach to ProjectManagement 40Module Summary 51
  2. 2. Information in this document, including URL and other Internet Web site references, is subject tochange 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 applicablecopyright laws is the responsibility of the user. Without limiting the rights under copyright, nopart of this document may be reproduced, stored in or introduced into a retrieval system, ortransmitted in any form or by any means (electronic, mechanical, photocopying, recording, orotherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectualproperty rights covering subject matter in this document. Except as expressly provided in anywritten license agreement from Microsoft, the furnishing of this document does not give you anylicense 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 eitherregistered trademarks or trademarks of Microsoft Corporation in the United States and/or othercountries.The trademark “PMBOK” is a registered mark of the Project Management Institute, Inc., in theUnited States and/or other nations.The names of actual companies and products mentioned herein may be the trademarks of theirrespective owners.
  3. 3. Module 2: Building an MSF Team iiiInstructor Notes This module provides students with a high level introduction to building a team that should enable students to be effective participants (as opposed to leads) on an MSF team. After completing this module, students will be able to: ! Discuss how six of the eight MSF foundational principles apply to the team model. ! Identify the major project goal that is associated with each team role cluster on an MSF project. ! Identify how to organize an MSF Team with a specific number of participants. ! Discuss how project management in MSF is distributed among team leads on large projects.Required materials To teach this module, you need the following materials: ! Microsoft® PowerPoint® file 1846A_02.ppt ! Materials listed in the Activities Appendix for the “Communicating in Teams” activity Important It is recommended that you use PowerPoint 2002 or later to display the slides for this course. If you use PowerPoint Viewer or an earlier version of PowerPoint, all the features of the slides may not be displayed correctly.Preparation tasks To prepare for this module: ! Read all of the materials for this module. ! Review the MSF Team Model white paper on the Microsoft Solutions Framework Web site at http://www.microsoft.com/msf.
  4. 4. iv Module 2: Building an MSF TeamHow to Teach This Module This section contains information that will help you to teach this module.Lesson: The MSF Team Model This section describes the instructional methods for teaching this lesson.Lesson: MSF TeamModel Purpose To set expectations for student learning in this lesson. Delivery ! Explain that this lesson focuses on the rationale for how the MSF team model was organized and the roles identified. ! Read the objectives on the slide.Activity: Communicating Purposein Teams To announce the communicating-in-teams activity. Delivery See activities delivery section in the instructor guide.Symptoms of PurposeChallenged Projects To discuss some typical problems with challenged or failing projects. Delivery This is a 2-build slide. ! Build 1. This shows the first group of quotes, which were made by customers and users of a solution. ! Build 2. The second group of quotes comes from team members who participated in the project. ! Note that all the quotes have been chosen because they are representative of typical types of problems encountered in projects. ! Ask students if these quotes sound familiar.
  5. 5. Module 2: Building an MSF Team vGoals for Successful PurposeProjects To demonstrate how the basic goals for successful projects contain the remedies for common project failures. Delivery This is a 3-build slide. ! 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?”
  6. 6. vi Module 2: Building an MSF TeamMSF Team Model Purpose To use the team model graphic to help students understand the way the MSF team model is structured and the reasons for this structure. Delivery This is a 3-build slide. ! 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.
  7. 7. Module 2: Building an MSF Team vii Note Do not drive deep into the roles, because each will be covered in depth later. Emphasize here the fact that although there are six role clusters, this does not mean there are always six people per project team. The details of scaling project teams will be discussed later; however, students often have difficulty with the distinction between a role and the person or persons filling it. Explain the difference right away to counter any thoughts that a role (cluster) is equal to an individual. (Also, see Background below.) Background The role cluster names are sometimes also used as job titles in the industry. However the distinction between job titles and the MSF role names should remain clear—that the purpose of the role is to associate a name with a key goal for project success, whereas job titles fulfill an organizational need for labeling positions.Other ProjectParticipants—External PurposeStakeholders To define the various parties outside the team that it communicates with throughout the project. Delivery ! Tell students that in order to achieve its goals, the team must identify key individuals or groups with whom they will work on the project and who have a “stake” in its outcome. These people are commonly known as external stakeholders. ! Read the definitions on the slide of the common stakeholder names as they will be used throughout this course, giving examples from your experience of the difference between customer, project sponsor, and end user. ! Emphasize that not only do teams need to be aware of who their external stakeholders are—they also need to establish working relationships with them. Note Instructors may need to refer back to this slide before or during the presentation of the slide and graphic “The Extended Project Team” that shows the internal team members who interact with these parties.
  8. 8. viii Module 2: Building an MSF TeamMSF Foundational PurposePrinciples Applied to To explain how MSF foundational principles guide the functioning of the team.Team Model Delivery Note There are six principles that are especially relevant to the team. These will be covered in two slides. This would be a good time (while discussing the principles) to refer back to the students’ flipchart list of reasons for project successes and failures, if any are related to the principles. 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.
  9. 9. 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.
  10. 10. x Module 2: Building an MSF TeamMSF Foundational PurposePrinciples and Team To present the second group of foundational principles that guide theModel (continued) functioning of the team model. Delivery This is a 3-build slide. ! 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.
  11. 11. 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.
  12. 12. xii Module 2: Building an MSF TeamKey Concepts and PurposeProven Practices To present key concepts and proven practices that are important to the team model. Delivery ! Explain that the concepts on the slide are descriptive of the MSF team model, and highlight attitudes and values that are called for among members. Describe them as follows: • The team of peers concept defines a team as a group of clearly defined roles, each owning a clearly defined goal that is necessary to the success of the project. The roles are seen as peers with equal say in decisions. This enables unrestricted communication between the roles, increases team accountability, and reinforces the belief that each of the six quality goals associated with the six roles is equally as important as the others and must be achieved. Note The team of peers is different from more traditional, hierarchical teams in that there is no project manager role (students are likely to ask about this). Project management is a function of the program management role as well as a responsibility that is shared among the role team leads. This will be discussed in detail later in the module. • A customer-focused mindset means that team members are continually mindful that satisfied customers are priority number one. Consequently, everyone on the team commits to understanding and solving the customer’s business problem. • A product mindset is a matter of viewing one’s work as part of a project that is aimed toward the delivery of a product, whether it is tangible or intangible. This mindset is important because it gives meaning to the work—it focuses on the real job of the team rather than the particular tasks any one member might carry out. A product mindset can increase motivation by giving teams a definite goal with which all members can identify. • A zero defect mindset represents a commitment on the part of every team member to attain a predefined quality bar in their work throughout the project. The concept should not be understood literally to mean no defects, but the building of quality into the development process as opposed to merely checking for it at the end. • Willingness to learn is a prerequisite attitude for successful teams that is related to the team of peers concept and the open communications principle. It has several applications: • Committing to self-improvement through gathering and sharing knowledge • Institutionalizing learning through such techniques as reviews and postmortems • Allowing team members to benefit from mistakes • Helping team members to repeat successes • Mandating time for the team to learn
  13. 13. Module 2: Building an MSF Team xiii ! Describe the three proven practices listed on the slide as follows: • The use of small, interdisciplinary teams is a natural corollary of the team of peers structure, with its definition of unique roles that require different skill and knowledge sets. Small, interdisciplinary teams: • Tend to be more agile than large teams. • Have roles that are interdependent but specialized and focused on their particular function. • MSF advocates locating a team on one site when possible, for these reasons: • It eliminates obstacles to communication by allowing frequent physical meetings and interactive exploration of ideas. • It helps to enforce the sense of team identity and unity. Note This does not preclude “virtual” teaming—it only makes it a secondary rather than primary choice. • All roles on the team participate in creating the functional specifications for the solution because each role has a unique perspective of the design and its relationship to their individual objectives, as well as the team’s objectives.Lesson Review Purpose To reinforce the main points of the lesson by asking questions. Delivery Ask the following questions. 1. How are project goals, project success, and the MSF team model related? Fundamental project goals must be equally valued and met. When these goals are understood and met, this is an indication that typical barriers to project success have been eliminated. The MSF team model represents one way to assign responsibility for meeting all project goals. 2. What does the circular structure of the team model represent? Nonhierarchical model—there is no project “boss.” Inclusion—all team members see themselves within the solution space. Interconnectedness and interlocking responsibilities of the role clusters. 3. Which of the eight MSF foundational principles are closely associated with the team model? Work towards a shared project vision. Focus on business value. Stay agile, expect change. Empower team members. Foster open communications. Establish clear accountability, shared responsibility. 4. What are some of the key concepts of the team model? Team of peers. Customer-focused mindset. Product mindset. Zero defect mindset. Willingness to learn.
  14. 14. xiv Module 2: Building an MSF TeamLesson: MSF Team Role Clusters This section describes the instructional methods for teaching this lesson.MSF Team Role Clusters Purpose To set expectations for student learning in 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.MSF Team Role Clusters Purpose To explore further the concept of role clusters and prepare for discussion of functional areas. Delivery ! Explain that a role cluster defines a common way to identify a combined set of functional areas and their associated responsibilities. The MSF team model has defined six role clusters, each associated with a quality goal of the solution. ! Explain that a role cluster may be one person or many team members, depending on the size and complexity of the project, as well as the skills required to fulfill the responsibilities of the functional areas. ! Explain that a functional area is a division of the role cluster into specific activities. For example, the functional areas of the test role cluster are test planning, test engineering, and test reporting. (Alert students that role clusters and functional areas will be explored in more detail in the next lesson.) ! Mention that tasking role clusters with goals that may be in tension with one another is deliberate and provides important checks and balances on the team. It accounts for the strength of the model in ensuring that decisions are informed by all perspectives and that all viewpoints are represented. ! Explain that a subsequent lesson will show how roles may be combined, and that some combinations have more risks than others, related to the loss of healthy conflicts between the roles. Optional Ask the class if they can see areas of potential conflict between the roles, where compromises will have to be made. They might suggest program management and product management (budget/time vs. features). Note Although the official wording is now role clusters—to distinguish the fact that each role has multiple (or a cluster) of functional areas associated with it—typically the word cluster is dropped and role clusters are referred to as roles.
  15. 15. Module 2: Building an MSF Team xvMSF Team Role Clusters Purposeand Their Functional To demonstrate that each role represents several related functional areas.Areas Delivery ! Point out that the range of activities required to fulfill the goals of each team role means that the roles each represent several related functional areas. ! Elaborate by pointing out that the functional areas are conceptually related in that they all serve the same goal but involve different responsibilities and require different skill sets. Note Do not go into detail about the functional areas at this time because, following a slide showing the structure of role clusters, the next six slides cover each role and its functional areas.Structure of MSF Team PurposeRole Clusters To clarify the relationship of functional areas, responsibilities, and tasks within role clusters. Delivery ! Explain that each role contains several functional areas, and that associated with each functional area are several responsibilities. These in turn contain tasks, which describe the work at a detailed level. ! Help students to understand the structure by stepping through the example as follows: • Program management is the name of the role cluster. • Project management and solution architecture are two of its functional areas. • Driving overall solution design and managing critical trade-off decisions are two responsibilities associated with solution architecture. • Identifying customer requirements and liaising with other project teams on interoperability issues are two of the tasks that must be done in order to drive the overall solution design. ! Explain to students that defining specific functional areas within each role is helpful when it is necessary to divide the work of the role between two or more persons.
  16. 16. xvi Module 2: Building an MSF TeamProgram Management PurposeRole Cluster To further define the program management role by mapping the role’s primary goal to its specific functional areas and responsibilities. Delivery Note This is the first of six slides that consider each role cluster and its primary goals and functional areas in turn. Responsibilities belonging to each functional area have been printed in the student notes. These details should be referenced only to help students understand the role’s primary responsibilities and how they are achieved. The slides should be delivered as interactively as possible in order to maintain student interest despite the repetition. ! Focus on the key goal of program management (to deliver a solution within project constraints) and touch on how each of the four functional areas complement each other in support of this goal. ! Briefly explain each functional area and mention some of the responsibilities listed in the student notes under these headings. ! Emphasize that many of the traditional responsibilities of project management, such as the schedule, feature set, and project budget, fall to the program manager, but this does not equate to the program manager having sole responsibility for project management. Alert students that a lesson focused on project management is upcoming. ! Note that process assurance is concerned with the quality of the process that is being used by the team as a whole to deliver the solution. For example, program management would determine the need to do risk management for the project and assure that the risk management process was sufficient to meet the goals of the project. This is different from quality control, which looks at the outcome of the process (the solution), not the process itself. ! Mention that program management ensures that the project sponsor’s expectations are understood and managed throughout the project.Development Role PurposeCluster 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.
  17. 17. Module 2: Building an MSF Team xviiTest Role Cluster Purpose To further define the test role by mapping its primary goal to its specific functional areas and responsibilities. Delivery ! Focus on the key goal of the test role (to approve for release only after all solution quality issues are identified and addressed), explaining that “addressing” all quality issues does not necessarily mean fixing all defects—it can also mean providing a work-around solution and documenting it. ! Touch on how each of the four functional areas complement each other in support of the key goal. ! 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.Release ManagementRole Cluster Purpose To further define the release management role through the mapping of the role’s primary goal to its specific functional areas and responsibilities. Delivery ! Focus on the key goal of release management (smooth deployment, ongoing operations) and touch on how each of the five functional areas complement each other in support of this goal. ! 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. ! Mention that the release management role is key to facilitating direct involvement of operations throughout the project life cycle. ! Identify to students the fact that this role cluster maps to the similar Microsoft Operations Framework (MOF) release management role cluster, and as such, acts as the liaison between MOF (operations) and MSF (solutions development) teams.User Experience RoleCluster 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. ! 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.
  18. 18. xviii Module 2: Building an MSF TeamProduct Management PurposeRole Cluster 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.The Extended Project PurposeTeam 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.
  19. 19. Module 2: Building an MSF Team xixLesson Review Purpose To reinforce the main points of the lesson by asking questions. Delivery Ask the following questions. 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.
  20. 20. xx Module 2: Building an MSF TeamLesson: Scaling Teams for Project Efficiency This section describes the instructional methods for teaching this lesson.Lesson: Scaling Teams Purposefor Project Efficiency To set expectations for student learning in 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.Ways to Scale Up Teams Purpose To explain the reasons for and ways to scale up MSF teams. Delivery ! Explain that complexity in a project may be related to: • Size—features and/or team. • Risks—higher risk may mean more resources to mitigate or greater skill specialties required. • Schedule—tight schedules may require more developers, testers, and so on. • Skills—outsourcing may be required to fulfill skill gaps. ! Describe what to do when team size increases, as follows: • Divide the team into a core team and sub-teams. • Have members of the core team function as team leads for the sub-team. At this point the core team becomes known as the lead team. (Note that this creates a hierarchical team structure but the structure is offset by team leads being peer participants on core team.)
  21. 21. Module 2: Building an MSF Team xxiFeature Teams Purpose To introduce the concept of a feature team. Delivery ! Explain that feature teams are sub-teams/projects that focus on building specific features or capabilities of a solution. They may be organized around a product feature set. ! Emphasize that feature teams are multidisciplinary. Explain that they typically have the four roles of program management (PM), development (dev), test, and user experience (UE) represented. Product and release management are normally focused externally on customers and end-users, and are thus not primary roles on feature teams. ! Ask students to notice that the team that is in the leadership position is called the lead team. As the project scales up in size, the core team must make a transition into a lead team, and take on lead team responsibilities. Example: At Microsoft, the Microsoft Office team is a lead team, and the applications teams such as Microsoft Word, Microsoft Excel, and Microsoft Access are feature teams, each with their own program managers. The Office team is responsible for such things as shared components and compatibility of the applications. ! Explain that feature team members may be involved in more than one feature team depending on requirements and complexity. Members: • Could perform one role on one feature team and another role on a different feature team. • Could also be part of a function team (discussed next) while fulfilling a role on a feature team. ! Note that the example shown in the slide is for an infrastructure project. ! Discuss with students an example of feature teams that might be formed for an application development or Web services type project.When to Use Feature PurposeTeams 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.
  22. 22. xxii Module 2: Building an MSF TeamFunction Teams Purpose To introduce the concept of a function team. Delivery ! Define the function team by reading the definition on the slide—a unidisciplinary sub-team that is organized by functional role. ! Explain that as discussed in the previous lesson, a role cluster contains many functions that require more than one person to fulfill that role when the function is needed, particularly when complex projects are being staffed. This scaling out of the role cluster to form function teams is usually a result of project size or complexity. ! Explain that function teams may have an internal hierarchical reporting structure. ! Use an example such as the following to explain why and how function teams are formed. Example: A large web development project that is fulfilling the role requirements of UE: • The skills and responsibilities required to fulfill the functions of user interface design and those of internationalization can be quite different. • Training/support material and usability research and testing functions might be fulfilled by one individual but because the project is a large scale project, require two people. • A UE lead is assigned to coordinate the efforts of the entire role function and to fulfill the project management duties at the function team level. • Alternatively, the technical communications and the UE lead responsibilities could be carried out by one person, and training/support material fulfilled by another person if the project needed to use fewer resources. ! Suggest that another possible combination is the release management role which facilitates the operations and logistics functions, with the product management role, for which the functional responsibilities include doing customer requirements research, advocacy, and marketing.When to Use FunctionTeams 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.
  23. 23. Module 2: Building an MSF Team xxiiiTeam Leads on Large- PurposeScale Projects To explain how team leads have project management responsibilities at the sub- team level. Delivery ! Explain that team leads have special requirements—to provide project management services to the core team (that has become the lead team) by taking on those responsibilities at the feature team level. Example: • Team leads facilitate cost and resource estimation for the sub-team and provide this input to the core team, which “rolls up” the data. • On behalf of their feature sub-team, team leads are responsible for planning/tracking resources and skills/readiness. • Team leads facilitate risk and quality management for the sub-team. ! Discuss the fact that this shared responsibility of project management is a key differentiator of MSF compared to methodologies, which generally prescribe a “top-down” approach. It is advantageous in that it: • Allows task estimation to occur where it is generally most accurate— with those who are actually doing the work. • Streamlines communication. • Keeps scope, cost, risk, quality, and other project management tasks a shared responsibility so team members feel a greater sense of ownership for success of their areas as well as the overall solution. ! Explain that as a project transitions through each phase there is a shift in the primary role accountable for that phase. With this shift comes a heightened responsibility for that role’s project management responsibilities. However, the overall solution project management is still owned by program management. ! Mention that more details on project management and MSF will be provided in the next lesson.MSF Sub-teams in PurposeRelation to the LeadTeam 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.
  24. 24. xxiv Module 2: Building an MSF TeamScaling Down— PurposeCombining Roles for To show the appropriate role combinations that help scale down an MSF team.Smaller Teams Delivery Note This is a 4-build slide that shows first the blank chart, then the possible, unlikely, and not recommended role combinations in turn. ! Build 1. Explain that the chart is set up like a mileage chart that shows the distance between cities. The intersection of the rows and columns is where to look to see if a particular combination is feasible. ! Builds 2-4. Click through the builds slowly enough for students to take in which role combinations are possible, unlikely, and not recommended. Explain that the use of Unlikely here means that finding an individual with the appropriate skill sets to fulfill both roles effectively is difficult, thus making the combination unlikely. The use of Not Recommended means that although a choice can be made to combine these roles, as with the unlikely combinations, there is a conflict in the required skills sets and even the goals of these roles. Combining them could significantly impair project success. ! Explain through discussion with students how to scale down the team by describing which combinations tend to work better and which are riskier roles to combine. This is a good opportunity to ask students to apply their understanding of the roles by suggesting some of the risks. • Ask why combining program management and development would be risky. If students don’t know, explain that it is never recommended to combine the development role with other roles, for the following reasons: • Development should be focused only on building the solution, not customer interaction or management tasks. Distractions during building can cause slips in the delivery schedule due to the dependencies typically involved with development deliverables. • Combining development with other role responsibilities is generally the most costly and riskiest—often leading to schedule slips. • Ask what might be some of the risks of combining product management and program management. If answers do not include this concept, explain that certain roles, such as product management and program management, should avoid being combined due to the conflicting focus and goal for each role—for example, “satisfied customer” versus “ship on time and within budget.” • Ask what might be some of the risks of combining development and test. Explain that developers cannot be expected to both build the entire functionality of the solution and check their work for quality. Additionally, the skills focus of the development and test roles are typically different, thus making a combination of these two difficult. ! Emphasize that it’s not that teams can’t or must not combine roles—rather that each combination generates risks that must be accounted for and managed. Emphasize the importance of the fact that even if a combination is risky, a greater risk is not having the role (and thus the associated goal for that role) represented on the team. ! Explain that team members fulfilling multiple roles should make it clear which role or roles they represent when they speak or offer guidance.
  25. 25. Module 2: Building an MSF Team xxvExample: Small Teams Purpose To provide an example of role combinations that have the least amount of risk. Delivery ! Use the graphic to provide students with an example of possible role combinations presented in the matrix. ! Note that these are not the only combinations, rather the ones that are “okay” and present the least amount of additional risk. ! Highlight the fact that the development role here is still isolated to keep the developers focused on building. ! Mention that the responsibilities of the test role in this scenario are typically floating responsibilities. • Coverage testing happens through the user experience (UE)/product management (PdM)/test combined role. • Usage testing, because it is validating the entire solution as a whole, would then occur through the program manager/release manager combination. Note that this is often a key point instructors miss when delivering the material. ! Discuss with students other possible combinations that might work, making sure to discuss their associated risks. Example: program management and test, with a higher risk of quality bar slipping to meet schedule/budget.
  26. 26. xxvi Module 2: Building an MSF TeamLesson Review Purpose To reinforce the main points of the lesson by asking questions. Delivery Ask the following questions. 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.
  27. 27. Module 2: Building an MSF Team xxviiLesson: A Scalable Approach to Project Management This section describes the instructional methods for teaching this lesson.Lesson: A Scalable PurposeApproach to ProjectManagement To set expectations for student learning in 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.The Project ManagementDiscipline 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.
  28. 28. xxviii Module 2: Building an MSF TeamProject Management PurposeKnowledge Areas To describe the various knowledge areas involved in project management. Delivery Use the information in the following table (also provided to students in student notes) to explain the project management knowledge areas. Knowledge area Includes such activities as: Project integration Integrating and synchronizing project plans management Setting up procedures and systems to manage Tracking change Project scope management Defining and breaking down scope of work Managing project tradeoffs Project time management Generating and maintaining schedules Task sequencing Matching resources to tasks Project cost management Preparing cost estimates Progress reporting and analysis Cost risk analysis Value analysis Project human resources Resource planning management Team building Conflict resolution Skills readiness training Project communications Communication planning management Project status reporting Project risk management Facilitating and driving team risk management Maintaining risk documentation Project procurement Soliciting contractor bids for services and/or management hardware/software Preparing requests for proposals (RFPs) Managing vendors/subcontractors Managing and negotiating contracts Preparing purchase orders and approving invoices Project quality Quality planning management Determining standards Documenting quality criteria and quality measurement processes Note These knowledge areas have been compiled by the Project Management Institute (PMI).
  29. 29. Module 2: Building an MSF Team xxixDistributing Project PurposeManagement on Large To explain how the specific areas of project management are distributed in aProjects scaled-up MSF team. Delivery This is a 5-build slide. ! Build 1. Tell the students that the matrix about to be shown clarifies how the various team leads distribute the responsibility for project management. Stress that it is important to clarify each team lead’s responsibilities in order to avoid problems. ! Build 2. Direct the students’ attention to the list of team leads. Remind the students that each lead is working with other individuals (not shown) in their sub-teams. ! Build 3. Mention that these (slanted text entries at top of chart) are the project management knowledge areas shown on the previous slide. ! Build 4. Explain that the MSF program management role cluster has project management responsibilities for the project overall. These are denoted by the solid dots. ! Build 5. Explain that each team lead has the project management responsibilities denoted by the hollow dots for their sub-team. Additional Notes Program and release management might both share in overall procurement responsibilities. This is because operations organizations already have established vendors and purchasing procedures in place. Program management, on the other hand, typically procures project resources (such as Web design, testing services, and technical writing) and makes miscellaneous project purchases. This helps the team to meet the goal of “delivery to constraints.”Special Responsibilitiesof Program Management Purpose To explain the special project management responsibilities of the program management role cluster. Delivery ! Explain that because the goal of the program management role cluster is delivery of the solution to project constraints, project management is critical to this role cluster. Point out that the terms “program management” and project management sound similar. Remind the students of the difference— otherwise the remainder of the lesson may be confusing. Program management is an MSF role cluster, whereas project management is a set of skills, techniques, and tools. ! Explain that larger projects may require dedicated full time expertise in project management. In these cases, a function team may be created to fill the program management role cluster.
  30. 30. xxx Module 2: Building an MSF Team Background The main idea here is that the design work, specifications writing, and managing schedules, budgets, coordination, and so on becomes overwhelming for one individual on larger projects. This problem is solved by a division of labor for the program management role cluster. The solution architect focuses 100% on design and specifications while the project manager focuses entirely on project management.Scaling Up Project PurposeManagement Functions To demonstrate the flexibility of the MSF team model to scale project management responsibilities from small to large projects. Delivery This is a 4-build slide. ! 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.
  31. 31. Module 2: Building an MSF Team xxxiAssessing Project PurposeManagement Complexity To help students assess the project management risks on their projects and gauge the level of project management readiness needed on their teams. Delivery ! Explain the chart in the slide, which maps projects according to two variables. The horizontal axis represents technical complexity, meaning technical difficulty and risks. As projects move toward high end locations on the axis, the team’s technical skill levels must also be higher to be successful. The vertical axis represents project management difficulty and risks. Again, as these increase, so must project management skill levels. ! Several factors for project management risk are shown in the list at the left of the graphic. Elaborate on these factors and tie them back to project management readiness. The key point here is that teams with great technical skills, but lacking in project management skills, still face a risk of failure. ! Focus on Project A and Project B on the chart. The technical risks are the same or similar, but project B faces additional project management risks. Point out that the same project management skills and processes that were sufficient for project A are likely to be insufficient in project B. ! Ask the students to provide examples from their experience of projects that would fit the various quadrants. Ask them how project management was conducted in those projects.Lesson Review Purpose To reinforce the main points of the lesson by asking questions. Delivery Ask the following questions. 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.
  32. 32. 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.SummaryModule 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.
  33. 33. Module 2: Building an MSF Team 1Module Overview ! The MSF Team Model ! MSF Role Clusters ! Scaling Teams for Project Efficiency ! A Scalable Approach to Project Management*****************************ILLEGAL FOR NON-TRAINER USE******************************Introduction The MSF team model is based on many years of experience Microsoft® has in forming small, multidisciplinary teams that successfully develop IT solutions.Objectives After completing this module, you will be able to: ! Discuss how six of the eight MSF foundational principles apply to the team model. ! Identify the major project goal associated with each team role cluster on an MSF project. ! Identify how to organize an MSF team with a specific number of participants. ! Discuss how project management in MSF is distributed among team leads on large projects.
  34. 34. 2 Module 2: Building an MSF TeamLesson: 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*****************************ILLEGAL FOR NON-TRAINER USE******************************Introduction This lesson introduces the MSF team model.Lesson objectives After completing this lesson, you will be able to: ! Describe why the MSF team model was created. ! Describe the MSF team model structure. ! Discuss the key concepts and proven practices of the MSF team model. ! Describe how six of the eight MSF foundational principles apply to the team model.
  35. 35. Module 2: Building an MSF Team 3Activity: Communicating in Teams Follow your instructor’s directions*****************************ILLEGAL FOR NON-TRAINER USE****************************** The instructions for this activity are in the Activities Appendix. Your instructor may have additional directions.
  36. 36. 4 Module 2: Building an MSF TeamSymptoms of Challenged Projects “The project was late and “What was over budget” built really “It doesn’t meet isn’t what our expectations – we needed” “We didn’t we’re not happy” understand clearly what we were “We couldn’t get supposed to do” the information “We were unaware we needed to of how the work of do our work” other team members “We can’t get affected our work” it to operate “It’s just too well in our “This thing is difficult to use” environment” unpredictable – we keep discovering new problems”*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.