• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
02.building a msf team
 

02.building a msf team

on

  • 1,118 views

 

Statistics

Views

Total Views
1,118
Views on SlideShare
1,117
Embed Views
1

Actions

Likes
0
Downloads
7
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    02.building a msf team 02.building a msf team Document Transcript

    • 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
    • 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.
    • 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.
    • 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.
    • 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?”
    • 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.
    • 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.
    • 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.
    • 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 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.
    • 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 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
    • Module 2: Building an MSF Team xiii ! Describe the three proven practices listed on the slide as follows: • The use of small, interdisciplinary teams is a natural corollary of the team of peers structure, with its definition of unique roles that require different skill and knowledge sets. Small, interdisciplinary teams: • Tend to be more agile than large teams. • Have roles that are interdependent but specialized and focused on their particular function. • MSF advocates locating a team on one site when possible, for these reasons: • It eliminates obstacles to communication by allowing frequent physical meetings and interactive exploration of ideas. • It helps to enforce the sense of team identity and unity. Note This does not preclude “virtual” teaming—it only makes it a secondary rather than primary choice. • All roles on the team participate in creating the functional specifications for the solution because each role has a unique perspective of the design and its relationship to their individual objectives, as well as the team’s objectives.Lesson Review Purpose To reinforce the main points of the lesson by asking questions. Delivery Ask the following questions. 1. How are project goals, project success, and the MSF team model related? Fundamental project goals must be equally valued and met. When these goals are understood and met, this is an indication that typical barriers to project success have been eliminated. The MSF team model represents one way to assign responsibility for meeting all project goals. 2. What does the circular structure of the team model represent? Nonhierarchical model—there is no project “boss.” Inclusion—all team members see themselves within the solution space. Interconnectedness and interlocking responsibilities of the role clusters. 3. Which of the eight MSF foundational principles are closely associated with the team model? Work towards a shared project vision. Focus on business value. Stay agile, expect change. Empower team members. Foster open communications. Establish clear accountability, shared responsibility. 4. What are some of the key concepts of the team model? Team of peers. Customer-focused mindset. Product mindset. Zero defect mindset. Willingness to learn.
    • xiv Module 2: Building an MSF 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.)
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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).
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • Module 2: Building an MSF Team 5Goals for Successful Projects Typical Symptom Related Project Goal Goal of Challenged Project for Success Ownership “The project was late and over Deliver within project ? budget” constraints “What was built really isn’t what we Build to specifications ? needed” “This thing is unpredictable – we keep Release with issues identified ? discovering new problems” and addressed “We can’t get it to operate well in our Deploy smoothly and prepare ? environment” well for ongoing operations “It’s just too difficult to use” Enhance user effectiveness ? “It doesn’t meet our expectations – Satisfy customers ? we’re not happy” “Needed information is not shared Establish good communications ? timely to all who need it”*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 6 Module 2: Building an MSF Team ! 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.
    • Module 2: Building an MSF Team 7MSF Team Model Delivering the solution within project constraints Program Satisfied Management Building to customers specification Product Management Development Communication User Experience Test Enhanced user Approval for release only effectiveness after all quality issues are Release identified and addressed Management Smooth deployment and ongoing operations*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 8 Module 2: Building an MSF TeamOther 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.Definition 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
    • Module 2: Building an MSF Team 9MSF Foundational Principles Applied to Team Model Work toward a shared vision Focus on business value Stay agile, expect change*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 10 Module 2: Building an MSF TeamMSF Foundational Principles and Team Model (continued) Empower team members Foster open communications Establish clear accountability, shared responsibility*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 11Key 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.”
    • 12 Module 2: Building an MSF Team 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.
    • Module 2: Building an MSF Team 13Lesson 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?*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 14 Module 2: Building an MSF Team 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.
    • Module 2: Building an MSF Team 15Lesson: 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*****************************ILLEGAL FOR NON-TRAINER USE******************************Introduction This lesson describes the MSF role clusters.Lesson objectives 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 that is associated with each team role cluster on an MSF project.
    • 16 Module 2: Building an MSF TeamMSF Team Role Clusters Program Management Product Management Development Communication User Experience Test Release Management*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.Definition 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).
    • Module 2: Building an MSF Team 17MSF Team Role Clusters and Their Functional Areas Project management Solution architecture Process assurance Administrative services Technology consulting Business value Program Implementation architecture Marketing Customer advocacy Management and design Application development Product planning Infrastructure development Product Management Development User Experience Test Accessibility Test planning Internationalization Test engineering User advocacy Release Test reporting Training/support material Usability research and testing Management User interface design Infrastructure Support Operations Logistics Commercial release management*****************************ILLEGAL FOR NON-TRAINER USE****************************** Each role contains several closely related functional areas that support the goal of the role.
    • 18 Module 2: Building an MSF TeamStructure of MSF Team Role Clusters Example Role cluster (role) Program management Functional areas Project management Responsibilities Solution architecture Tasks Drive overall solution design Manage functional specification Maintain traceability map Liaise with other project teams on interoperability issues*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 19Program Management Role Cluster ! Goal: To deliver solution within project constraints ! Functional areas " Project management " Solution architecture " Process assurance " Administrative services*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • 20 Module 2: Building an MSF TeamDevelopment Role Cluster ! Goal: To build according to specifications ! Functional areas " Technology consulting " Implementation architecture and design " Application development " Infrastructure development*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • Module 2: Building an MSF Team 21Test 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • 22 Module 2: Building an MSF TeamRelease Management Role Cluster ! Goal: To achieve smooth deployment, ongoing operations ! Functional areas " Infrastructure " Support " Operations " Logistics " Commercial release management*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • Module 2: Building an MSF Team 23User Experience Role Cluster ! Goal: To enhance user effectiveness ! Functional areas " Accessibility " Internationalization " User advocacy " Training/support material " Usability research and testing " User interface design*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • 24 Module 2: Building an MSF TeamProduct Management Role Cluster ! Goal: To satisfy customers ! Functional areas " Business value " Marketing " Customer advocacy " Product planning*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
    • Module 2: Building an MSF Team 25The Extended Project Team Business Focus Users Help User Product Desk Experience Management Customer Test Project Team Operations and Development Support Groups Release Program Project Management Management Sponsor Technology Architects and Steering Committees Technology Focus*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 26 Module 2: Building an MSF TeamLesson 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?*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 273. 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.Now is the time to ask any further questions you might have about the materialpresented in this lesson.
    • 28 Module 2: Building an MSF TeamLesson: 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*****************************ILLEGAL FOR NON-TRAINER USE******************************Introduction 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.Lesson objectives 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.
    • Module 2: Building an MSF Team 29Ways 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 30 Module 2: Building an MSF TeamFeature Teams Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability Program Management Product Management Development Lead Team User Experience Test Program Program Release Program Program Management Management Management Management Management Development Development Development Development Desktop Messaging Feature Feature User User User Experience Experience Team Test Test Experience Experience Team Test Test Program Program Management Management Development Development File and Print User Feature Test Test Experience Experience Team*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.Definition Term Definition Feature team Multidisciplinary sub-team that is created to focus on building specific features or capabilities of a solution
    • Module 2: Building an MSF Team 31When 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 32 Module 2: Building an MSF TeamFunction Teams Unidisciplinary sub-teams organized by functional role Team lead User interface Accessibility design User Experience Usability Training/support research and material testing Internationalization User advocacy*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 33When 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 34 Module 2: Building an MSF TeamTeam 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 35MSF Sub-teams in Relation to the Lead Team Lead team Program Management Function team Product Management Development Role Lead User Test User Experience Experience Program Program Release Program Program Management Management Management Management Management Development Development Development Development Desktop Messaging Feature Feature User User User Experience Experience Team Test Test Experience Experience Team Test Test Program Program Management Management Development Development File and Print User User Feature Test Test Experience Experience Team Feature teams*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 36 Module 2: Building an MSF TeamScaling Down – Combining Roles for Smaller Teams Roles may be combined, but some combinations pose risks Product Program User Release Development Test Management Management Experience Management Product Management N N P P U N N U U P Program Management Development N N N N N Test P U N P P P U N P U User Experience U P N P U Release Management P Possible U Unlikely N Not Recommended*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 37Example: Small Teams Small team, combined roles User Program Experience Management Development Product Release Management Management Test*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 38 Module 2: Building an MSF TeamLesson 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?*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 393. 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.Now is the time to ask any further questions you might have about the materialpresented in this lesson.
    • 40 Module 2: Building an MSF TeamLesson: 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*****************************ILLEGAL FOR NON-TRAINER USE******************************Introduction 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.Lesson objectives 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.
    • Module 2: Building an MSF Team 41The 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 42 Module 2: Building an MSF TeamProject 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** For each knowledge area∗, activities that an MSF project might require are listed below. 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 resource Resource planning management Team building Conflict resolution Skills readiness training Project communications Communication planning management Project status reporting *Source: Knowledge areas from Project Management Institute.
    • Module 2: Building an MSF Team 43(continued)Knowledge area Includes such activities as:Project risk management Facilitating and driving team risk management Maintaining risk documentationProject procurement Soliciting contractor bids for services and/ormanagement hardware/software Preparing requests for proposals (RFPs) Managing vendors/subcontractors Managing and negotiating contracts Preparing purchase orders and approving invoicesProject quality management Quality planning Determining standards Documenting quality criteria and quality measurement processes
    • 44 Module 2: Building an MSF TeamDistributing Project Management on Large Projects Team leads for each role own the responsibilities corresponding to the listed knowledge areas t t en en t n t gem agem en na an m me nt Ma M na ge t t ge e nt t n en ana gem eme men ions urce t Ma eme gem e t o n n M ana anag nag nica Res eme anag ana tio M a u n r M egra ope me M st M omm uma rocu isk M ality Int Sc Ti Co C H P R Qu Team Leads Program Management Product Management Development Test User Experience Release Management at overall project level at sub-team level*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 45Example: On a large team, the test lead gathers estimates from the rest of thetest team (sub-team) for inclusion into overall cost and schedule estimates. Withample input from the test team, the test lead is the point person for creating thetest plan, tracking testing tasks, determining work assignments of varioustesters, identifying testing-related risks, communicating test data and status ofthe test team, and acting as formal spokesperson for the test team. The test leadalso 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 reviewoverall project progress. She also meets with the test team at least once a weekto 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 gathersestimates from the other team leads and prepares the cost and scheduleestimates. With input from the team leads (a team of peers) the programmanager integrates the various plans into a master plan, synchronizes theschedules, consolidates all the risks into a project risk document, communicatesproject status on behalf of the whole team each week, and is the main point ofcontact for specific project-related issues. The program manager also notes thequality standards and procedures used by the other roles and follows up withthe appropriate team leads if they are not followed.*Source: Knowledge areas in graphic from Project Management Institute.
    • 46 Module 2: Building an MSF TeamSpecial 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 Project Program Solution Manager Management Architect Example of function team for program management*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 47Scaling Up Project Management Functions At three levels of scale… ! When project management management by # " ! When all are filled by subteams, becomes complex… team roles are filled roles project Program Management six persons or less… each with a team lead… becomes complex… …who is participating in Product …project managementDevelopment …program management owns Management isfunction project management? distributed among team leads project management activities team includes solution architect and Experience manager project User Test " Whenwith a are filled by subteams, each roles team lead… Release Program Program Management Management Management … program management function team includes solution architect Product and project manager Management Development Product ManagementUser Development Experience Test # When all team roles are filled by six persons or less… Release Management … project management is Program distributed among team leads Management User Product Management Experience Development Test User Experience Test Release Release Management Management … program management owns project management activities*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 48 Module 2: Building an MSF TeamAssessing Project Management Complexity ! What are your project management risks? " Large size or Project D cost Project Management Complexity Project C " Geographically High dispersed Project B " Multiple organizations " Contractual, legal issues Project A Low " Fixed budgets, schedules Project E Low High Technical Complexity*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • Module 2: Building an MSF Team 49Lesson 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?*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
    • 50 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. Now is the time to ask any questions you may have about the topics presented in this lesson.
    • Module 2: Building an MSF Team 51Module 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*****************************ILLEGAL FOR NON-TRAINER USE****************************** Now is the time to ask any questions you may have about the topics presented in this module.
    • THIS PAGE INTENTIONALLY LEFT BLANK