The MSF Team Model describes an approach to structure organizations, teams, individuals, and activities to maximize quality, productivity, and chances for success. It defines interdependent, multidisciplinary roles and their responsibilities, goals, and activities in context of the foundational principles and mindsets (e.g., team of peers). The MSF Team Model is based on the premise that each team member presents a unique perspective on a project. Yet, for project success, customers and other stakeholders need an authoritative single source of information on project status, actions, and current issues. To resolve this dilemma, the MSF Team Model combines clear accountability to various stakeholders with shared responsibility among the entire team for overall project success. The MSF Team Model is perhaps the most distinctive aspect of MSF. At the heart of the Team Model is the fact that projects must embrace the disparate and often juxtaposed perspectives of various stakeholders, including operations, the business, and users. The MSF Team Model fosters this melding of diverse ideas, thus recognizing that projects and their team structure need to be flexible enough to foster those ideas all while supporting the various teams in how they prefer to organize themselves to help foster innovation that comes from those ideas. Team of AdvocatesBuilding on the team of peers mindset, the MSF Team Model is based on advocacy. A project team and their respective advocacies are segmented into seven groupings (called advocacy groups). Each advocacy group, identified in Table 4-1 and depicted in Figure 4-1, champions a few complementary, and sometimes competing,[1] aspects of working together to deliver a solution. Each advocacy group gives its respective external groups a voice on the team and is key to setting and managing the expectations of the external groups, which the team will deliver against (i.e., two-way advocacy). The core of this model is the concept that every team member is an advocate for achieving and championing his or her respective quality goals; advocating for his or her respective stakeholders (i.e., constituents); and advocating for his or her corporate functional area (e.g., the marketing department).
Figure 4-1. MSF Team Model
Although Figure 4-1 presents a logical depiction of the team model and is not an "org chart," there remains a formidable challenge of creating an adaptable, scalable, and flexible team structure that enables the team to advocate for their respective advocacies, namely, the following:
The following sections discuss these aspects and how roles relate to advocacy groups, and then provide an in-depth discussion of each advocacy group. Quality Goals: Team of Quality ChampionsMSF is based on a belief that key quality goals must be achieved for a project to be considered successful. Reaching these goals typically requires the application of different sets of related skills and knowledge areas. Failure of one group to achieve its goals jeopardizes a project. Therefore, each group is considered equally important in this team of peers. These goals drive a team and define a team model. What is important in the adoption of the MSF Team Model is that all quality goals have an advocate on the team. Although it is true that the entire team is responsible for a project's success, the team model associates each quality goal with an advocacy group to ensure accountability and focus. That way, the various project stakeholders know who on the team is accountable for each goal. Table 4-2 states key quality goals and maps them to their respective advocacy group. Following the table, each goal is discussed.
Satisfied StakeholdersTo be successful projects must meet stakeholder needs. A solution must match or exceed stakeholder expectations. It is possible to meet budget and time goals but still be unsuccessful if stakeholder needs have not been met. It is also possible to meet stakeholder needs but be unsuccessful if there is an expectation mismatch. Coordinate Identification and Optimization of Project ConstraintsAs discussed in Chapter 2, "Understanding Solution Delivery Environments," solution delivery is subject to many constraints (e.g., budget, schedule, and resources). These constraints need to be quantified and their impact determined and balanced so a delivery team knows how best to work within the constraints. Because constraints can come from many aspects of solution delivery, each advocacy group is responsible for identifying and quantifying its own constraints. Optimizing and balancing these constraints for a given project is the responsibility of the Program Management Advocacy Group. Define Solution Within Project ConstraintsAs discussed in Chapter 7, "MSF Envision Track: Defining a Solution," a solution definition describes how users and administrators use and interact with a solution as well as how a solution behaves and interacts with its host environment(s). The advocates for a solution definition need to collaborate with their constituencies to work through the challenges of defining a solution within project constraints. Because it is not always possible to define a solution within all constraints, trade-offs need to be made. Deliver Solution Within Project ConstraintsThese advocates work with their consistencies to deliver a solution that optimally complies with project constraints. As discussed later, MSF provides a means to consider, balance, and optimally satisfy these constraints. Design Solution Within Project ConstraintsA successful design ensures that all aspects of a solution design meet or exceed project constraints, including training plans, pilot plans, deployment plans, and so forth. As discussed in Chapter 8, "MSF Plan Track: Planning a Solution," designing a solution involves a gradual evolution from high-level, conceptual designs to low-level, implementation designs. Build Solution to SpecificationSolution specifications describe in detail deliverables to be provided by a team to customers. It is important for a team to deliver in accordance with the specifications as accurately as possible because the specifications represent an agreement between a team and customers as to what will be built. Confirm All Aspects of a Solution Meet or Exceed Their Respective, Defined Quality LevelsAll solutions have issues. However, as discussed in Chapter 10, "MSF Stabilize Track: Stabilizing a Solution," to achieve defined quality levels, all issues deemed as release-blocking need to be addressed. As discussed later, this can involve everything from fixing an issue to documenting a workaround to closing the issue as "by design." Maximize Solution UsabilityThe purpose of a solution is to make it easier for users to perform their work. Otherwise, why would users use a solution? It would likely be easier to perform the work manually. Delivering a solution that is rich in features and content but that is not usable by its designated users is considered a failure. Maximize User Readiness and EffectivenessA well-crafted solution and a poorly crafted solution are equally inadequate if intended users do not have sufficient skills and understanding of how to use and interact with either solution. To be successful, solution delivery needs to address user readiness (sometimes referred to as user enablement), be it through training, support, or instructional manuals. Smooth Deployment and Transition to OperationsOften, the work necessary for a smooth deployment and transition to operations is underestimated. A smooth transition consists of not only making sure component parts of a solution are ready but also making sure Operations is ready to receive a solution and is prepared for the ongoing support and sustainability of a solution (i.e., operational readiness). How does a project team make sure the Operations team is ready? The answer to this question is very situational. This might include ensuring that training, infrastructure, and support are in place prior to deployment. Oftentimes, it is best to have some of an Operations team on a delivery team so they can bring their knowledge and experiences back to Operations. Another challenge related to a smooth deployment is the association of the ease of deployment with solution quality. Although seemingly illogical, it makes sense because the first exposure to a solution is with solution installation. If solution installation is faulty, unfriendly, or complicated, it often leads users to assume that the installed solution is similarly flawed, even if that is not true. Constituents: Team of AmbassadorsThe MSF Team Model embodies a team of peers brought together to represent the entire set of constituencies: internal or external organizational entities (groups or individuals) involved with sponsorship, promotion, production, use, administration, and maintenance of a solution. Each advocacy group is accountable for representing specific needs of its constituencies. No advocacy group's interests are more important than another's. With each group contributing its unique perspective of its representative constituency, together these views provide the necessary checks and balances to ensure that a team produces the right solution. The MSF Team Model advocates basing team decisions on sound understanding of customers' business and on active stakeholder participation throughout a project. To facilitate deep levels of participation, it is recommended that customer and user advocacy roles within the Team Model are staffed by members of the business and user communities.
Functional Areas: Team of RepresentativesA functional area is defined as a specialization within a general grouping of activities within an advocacy group. For instance, within the User Experience Advocacy Group, discussed in detail later, there are six functional areas (e.g., User Interface Design); each is responsible for a distinct aspect of user experience. The MSF Team Model emphasizes the importance of aligning advocacy groups by business needs. Keep in mind that "business needs" are not just customer needs, they also include internal needs coming from the various corporate functional areas (e.g., the training department)often the internal teams providing staff to be on a project. Team members, therefore, are representatives of their internal team and are advocates for the team's needs. Foundational Principles Applied to TeamingThe following are the MSF foundational principles applied to the MSF Team Model. Foster Open CommunicationsAs team size grows, so does the importance of good communications. Open communications is fostered by how a team is structured and what guidance is provided on which cross-team interactions are required. A team needs to be structured so that clear roles and responsibilities exist. Part of those responsibilities is to establish communications channels among roles. Open communications encourages healthy debate and discussions regarding different aspects of solution delivery. One tricky aspect of fostering open communications is balancing a team structure that encourages sharing across the advocacy groups but not to a point that grouping team members together reduces productivity. Conversely, separating them too much creates isolated, nonintegrated groups (i.e., team fragmentation).
Work Toward a Shared VisionEstablishing a shared vision is facilitated by appropriately organizing a team into feature and function teams (discussed in the sections titled "Feature Teams" and "Function Teams" later in this chapter). When it is important to have a cross-role understanding of a solution, feature teams work best. When it is important for cross-solution consistency, function teams work best. Empower Team MembersThe MSF team of peers mindset is an empowering concept. Each team contributes to the management and success of delivering a solution. There is preferably no "boss" telling team members what to do. Ideally, it is up to a team to reach consensus on what is best and how to implement. As such, each advocacy group is responsible for self-organizing to be able to best deliver on their commitments. Establish Clear Accountability, Shared ResponsibilityEveryone is responsible for a solution and is held accountable for performing his or her assigned role. The team of peers mindset does not cloud accountability; there is always a single person that is accountable for each aspect, task, and deliverable. Sharing responsibility across a team of peers means that everyone succeeds or fails togetherunlike other models where the overall manager is responsible. Deliver Incremental ValueAlthough all advocacy groups strive to add business value to a solution, two advocacy groups are dedicated to it (i.e., Product Management to connect with customers, and User Experience to connect with users). Both groups work with the others on the team to make sure what is being built incrementally has high customer value. Stay Agile, Expect and Adapt to ChangeOne aspect of staying agile is the ability to reorganize a team structure to fit best how a team thinks it will work best. For instance, let team members organize themselvesincluding if it means rearranging tables in their team room. Many times organizations are not flexible enough and force a team to fit into an existing structure that rarely is optimal for the team. Being agile also means that team members should be comfortable with being added to a team and rolled off as needed to respond to changing requirements and changing needs for skills necessary to deliver a solution. Too many times, team members get comfortable on a team and feel slighted if they are rolled off. If an organization's culture supports this dynamic staffing concept, it likely will be an invigorating culture that enables employees to seek tasks that they want and are skilled at providing. Invest in QualityBreaking up a team into seven advocacy groups, even if it is just locally, requires a concerted effort to communicate openly and collaborate effectively. However, structuring a team this way helps increase quality through a set of natural checks and balances where each role is validated by another. It enables each group to focus on its mission and create natural tension with competing goals. For instance, Product Management often tries to get as many features into a release, whereas Program Management wants to deliver within constraints and therefore tends to minimize the number of features. Learn from All ExperiencesSetting up a balanced team is not easy. Often, there are too many outside influences and challenges for a team to assemble their "dream team." As such, an organization must amass a body of experience and knowledge in teaming strategies that work. This includes how to divide into subteams, team chemistry, distributed teaming, and collaboration tools that support colocated teams as well as globally dispersed ones. Partner with CustomersThe MSF team roles are set up to maximize coordination with customerseach advocacy group has a distinct set of constituencies. To advocate successfully, each advocacy group must establish a good working relationship with its constituencies. Through these relationships, a team can better represent customer expectations, requirements, issues, and concerns. MSF Team Model FundamentalsBefore discussing MSF Team Model advocacy group particulars, a few underlying topics need to be discussed, namely, how roles relate to advocacy groups and functional areas; how the MSF Team Model fits within an organization; and how project management discipline is needed across a team. Relating Roles to Advocacy Groups and Functional AreasIt is important to understand the differences between an advocacy group, a role on a project team, and a functional area and how team members fit into the whole picture. As stated previously, an advocacy group is a clustering of like responsibilities, goals, and activities for the express purpose of advocating specific quality goals, constituencies, and internal corporate functional areas, as exemplified in Figure 4-2. Each advocacy group (e.g., Development) can subdivide its work into a more refined collection of responsibilities, goals, and activities that is assigned to specific functional areas (e.g., Database Development). The specifics of which functional areas are relevant vary from project to project. Figure 4-2. Example of an advocacy group decomposed into functional areas and responsibilities
A role is a logical means to refer to the lowest subdivision of labor and responsibility across all advocacy groups (i.e., it is the lowest level on a team structure within each advocacy group). Roles can be at different levels across a team (i.e., it is very likely that all roles will not be at the same level of specialty). For example, if an advocacy group does not use functional areas, the "role" maps to the whole advocacy group (e.g., "tester" would generically refer to the Test Advocacy Group). If an advocacy group uses functional areas (e.g., the Test Advocacy Group decides to split their work into functional testing and systems testing), a role maps to each functional area (e.g., functional tester and systems tester). If an advocacy group feels it is necessary to decompose their functional area into subspecialties, a role maps to the subspecialty level. On small teams (e.g., system performance tester), a role is typically at an advocacy group level because there might not be enough people to specialize. On moderate-sized teams, roles are most often assigned at a functional area level. On large teams, a solution is complex enough that functional areas often need to be subdivided into specialty areas. As such, roles on large teams are defined to match that level. Note that one role is not the same as one personmultiple people might perform the same role (e.g., many team members might fill the role of "tester"). Alternatively, to scale down a team, a team member might take on more than one role. Note that roles do not equate, imply, or suggest any kind of corporate organization chart or set of job titles because these vary widely by organization and team. Most often, project roles are staffed by people distributed among different corporate entities and sometimes within the business user community, as well as by external consultants and partners. To help clarify this for stakeholders and team members, it is best to document each team member's corporate position and title (e.g., Director of Finance) and his or her role on a project (e.g., Business Analyst role within the Product Management Advocacy Group). It is key to have a clear determination of the individuals on a team that are fulfilling a specific role and its associated functions, responsibilities, and contributions. Otherwise, by default, people assume a team member's corporate role matches that person's project role, which is often an incorrect assumption. Define and Design a Solution with All Roles RepresentedAlthough not everyone on a team might have helped define or design a solution, each advocacy group should have a representative involved. This is essential because each one represents a different aspect of solution delivery. Each has a unique perspective of a solution and its relationship to his or her individual objectives, as well as a team's objectives. Representatives from every advocacy group collaborating on the definition and design of a solution leads to a richer solution. This might be foreign to some organizations that typically rely heavily on their technology folks (e.g., architects) to come up with a design. However, solution designs that consider operations, user readiness, testability, and so forth tend to be more successful over the life of a solution. To put this in perspective, it is unfortunate but true that sometimes a well-designed solution has deployment issues (e.g., problems with legacy system integration). Typically, this is because a team put most of their efforts into feature design and not enough into deployment design. Although this might have looked like the right decision during planning, that decision can delay the whole rollout because it necessitates reworking a solution for it to be deployed successfully. Another example of this is designing a solution to facilitate testing. In this case, solution deployment could be delayed because testing was not performed as expeditiously as expected. The MSF Team Model Is Not an Organization ChartOne question that often arises when applying the MSF Team Model is: "Who is in charge?" An organization chart describes who is in charge and who reports to whom. In contrast, the MSF Team Model describes key roles and responsibilities for a project team, but does not define a management structure of a team from a personnel administration perspective. In many cases, a project team includes members from several different organizations, some of whom might report administratively to different managers. Certain situations might arise, however, in which a team does not come to consensus on an issue. After spending due diligence in trying to come to agreement, the role of Program Management must step up and temporarily take the primary lead to break a gridlock and move a project forward. It is during these instances that team members understand the leadership that has typically been shared among the roles must be temporarily shifted to an authoritative style to break the deadlock. This understanding creates a stronger level of acceptance and buy-in from the team on the need for an authoritative decision. As soon as the issue has been resolved and a team is able to get back into consensus, there is an immediate shift back into shared leadership responsibilities. A team of peers can be flexible and adaptable enough to handle these challenges successfully yet remain a nonhierarchical approach to project teaming. Use Small Teams, Working in Parallel with Frequent Synchronization PointsMany books discuss ideal team size. There is no universally correct answer. Conversely, each solution delivery approach or method has its own ideal. For instance, some agile approaches effectively use pair programming (i.e., team size equals two) whereas others suggest breaking a project team into groups of between 5 and 10 people. Irrespective of how a team is organized, a goal is to have efficient teams that work in parallel and that can easily integrate and synchronize their efforts. Influences on making this team-size decision include how easily project work lends itself to decomposition and the skills of a project team (i.e., more senior folks are better able to work independently). Project Management DisciplineWhy is it that when most people see or hear something like "project management discipline" they either recoil or snicker about the lack of discipline on their team? So with this type of visceral reaction, why would MSF advocate that everyone needs to exhibit good project management discipline? Because a key to building trust that leads to empowerment is when everyone develops mutual confidence in each other's ability to manage themselves and their portion of solution delivery adequately. This is not to say everyone needs to be a project manager; it is to say that to varying degrees all team members need to exhibit good project management discipline. It is also a key to scaling up a project team. Without adequate project management rigor, scaling up a project team quickly erodes into dysfunction. According to the Project Management Institute, "Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.[2] It is about using a body of knowledge and best practices to better enable a team to reliably deliver, adequately plan for risk, and reasonably manage its sphere of influence as opposed to being "the boss." It is about looking beyond the obvious, and planning for the unknown and the uncertain. It is confidently assessing and estimating what needs to be accomplished given project constraints and risks.
Part of developing good discipline is when team members assemble their own body of knowledge for the various types of projects and roles they might encounter. Whether managing a large program or a small solution component, a team needs context from which to understand how its current situation compares to other efforts. Figure 4-3 is an example of one such context. In this example, perceived project management complexity is mapped to perceived technical complexity for each project. As an organization starts to form a landscape of project types, each team builds off this experience to mature various successful approaches and behaviors to increase their ability to deliver reliably and repeatedly on commitments. In other words, a team is maturing their project management discipline. Figure 4-3. Example of assessed project complexity
Part of increasing each team member's project management discipline is broadening their project management awareness and maturing their delivery of activities. If done right, project management should be perceived as value-added activities that "protect" a team and enables them to focus on doing their work. The following project management planning activities should be considered for every effort and implemented as appropriate:
When a team has identified the various project management planning activities that are relevant, it is necessary to decide which team leads are responsible for the various activities and at what level of participation. Figure 4-4 is an example of one way to communicate this information. This concept scales as subteams are added to a project team. Each team lead and subteam lead is responsible for project management activities for their respective team. Figure 4-4. Example of various levels of team leads' project management responsibilities
Product Management Advocacy GroupThe Product Management Advocacy Group acts as a managed conduit between the business world and a project team. In the beginning of a project life cycle, they drive gathering requirements, expectations, and constraints and distill them into a solution definition. As a project progresses, Product Management works with the team to clarify what has been gathered and works with stakeholders to refine expectations. As a solution starts to take form, they reverse the conduit flow to start to prepare stakeholders for the coming solution. AdvocatesSolution definition ConstituencyProduct Management team constituents include the following:
Because it might be a bit confusing to understand the difference between a sponsor and a customer, here is an example scenario: an organization has five business units and an information technology (IT) department. One of the business units agrees to sponsor a line-of-business solution that all units will use. In this example, all five business units are "customers" because they will gain business value from the solution. The business unit that is paying for and approving the solution is also the project sponsor. The IT department is the Operations team. Users are employees from those five business units as well as any legacy solutions that will interact with the new solution. An example in which a project sponsor was not a customer was when organizations commissioned Y2K teams to sponsor projects to analyze and resolve "year 2000" issues. Another example is when an IT department sponsors projects for business units. Quality GoalsThe quality goals for Product Management are the following:
FocusProduct Management ensures that all stakeholder expectations are understood, managed, and met throughout a project. In addition, Product Management ensures that a project sponsor is satisfied with the progress and outcome of a project. To be effective, Product Management needs to understand, communicate, and ensure success from a stakeholder perspective. To do this, they need to gain knowledge about customers' business, success factors, and key performance measures. They own and drive the definition of requirements and feature sets as well as help the team understand user profiles and how users will use a solution. As you can tell, it is a very communications-oriented group. As discussed previously about partnering with a customer, the Product Management Advocacy Group leads this effort. They collaborate with customers to drive a solution vision and adjust both the vision and expectations as a project continues. It cannot be stressed enough how critical it is to manage customer expectations. Stuff happensno plan is able to cover all project impacts, and as such, sharing that information in a no-fault environment is very important and healthy. The importance of effectively managing expectations can be illustrated with an example involving the anticipated delivery of five solution features from a team to a customer by a certain date. If a team delivers only three features when a customer expects delivery of all five, a project will be deemed a failure both by the customer and by the team. If, however, Product Management maintains constant two-way communication with the customer during a feature development and production period, changes are made with regard to customer expectations that ensure success. Product Management might include customers in the trade-off decision-making process and inform them of changing risks and other challenges. Unlike the previous scenario, customers can assess the situation and agree with the team that delivery of all five features within the specified period is unrealistic and that delivery of only three is acceptable. In this scenario, the delivery of three features now matches the customer's adjusted expectations, and both parties will consider the project a success. Functional AreasThe Product Management Advocacy Group consists of several functional areas, including Marketing/Corporate Communications, Business Analyst, and Product Planning.
Marketing/Corporate CommunicationsBefore you go saying, "This is an internal project; we do not need Marketing on our project," please understand that this functional area is the process or technique of promoting, selling, and distributing a product, solution, or service. Nearly every solution needs to be introduced and promoted, even if it is a solution being rolled out internally to employees. When solution promotion is internal-facing, some organizations refer to this area as Corporate Communications. Whether it is called a marketing plan or a corporate communications plan, this plan needs to outline how to excite the target audience. After all, not everyone will welcome change; even if it is a new and improved solution. Typical promotional efforts on a project involve launch promotions, sustained promotions, and public relations. Promotional efforts run the gamut from sending out fliers and e-mail to full advertising campaigns. Key ResponsibilitiesThis functional area and the others to follow have key responsibilities. Key responsibilities for this functional area include the following:
Key ActivitiesEach functional area has a set of key activities to help uphold its responsibilities. Some activities are done throughout a project; some are done each iteration. Key activities for this functional area include the following:
Business AnalystA Business Analyst functional area works in conjunction with a sponsor(s) to gather, manage, and refine throughout the life cycle all the market information, all functional and operational requirements, all stakeholder expectations, and anything else that could affect the definition and delivery of a solution. To start, a Business Analyst team forms an initial vision and conceptual understanding of a solution, given insight of business needs and opportunities as well as the competitive landscape. As a solution vision, solution road map, and constraints are worked into high-level requirements, business analysts work with product planners (discussed next) to segment a solution into projects to deliver capability incrementally. Key Responsibilities
Key Activities
Product PlanningAs opposed to a Business Analyst functional area that is more externally focused, a Product Planning functional area works with the team on a tactical level, as depicted in Figure 4-5. Product planners take a vision and conceptual solution and drive a delivery strategy. Figure 4-5. Depiction of Product Management functional areas to stakeholders and the team
As discussed in Chapter 6, "Establishing a Solution Delivery Life Cycle," MSF recommends that solutions be incrementally delivered through versioned releases. A release is a bundling of solution features and capabilities so that it can be shared either internally among the team or externally with stakeholders. A Product Planning functional area coordinates and manages versioned solution releases. A release can encompass one or more teams' efforts. For instance, a release might be made up of new features from some teams and updates from others with previously released features. This functional area coordinates with Product Management from each of the subteams to present an integrated solution version for release. Product planning entails understanding the requirements of a solution completely, including what the needs of the business are, how customers will use it, what support issues will be, and what alternatives are available. It also entails working with the team to agree upon prioritization of requirements, capabilities, and feature sets; issues; risks; and so forth. Key Responsibilities
Key Activities
Program Management Advocacy GroupThe Program Management Advocacy Group guides solution delivery. At the heart of it all, Program Management involves building on the past, managing the present, and forecasting the future. It involves continual balancing and optimization of known constraints as well as managing risks to mitigate what might happen. And with changes and pressures from all angles, Program Management still needs to plot a steady course to deliver a solution with the agreed-on set of features and capabilities when promised. The MSF Team Model is based on a team of peers as discussed in Chapter 3, "Foundational Principles, Mindsets, and Proven Practices." Given that in most organizations, Program Management "owns" a project, the team-of-peers concept might seem foreign. Program Management owns part of a project but shares leadership of a project with the leads from the other advocacy groups. Not sure you get it yet? No worriesthis is discussed in more detail in subsequent chapters. Advocates
ConstituencyProgram Management team constituents include the following:
Quality GoalsThe quality goals for Program Management are as follows:
FocusProgram Management's main mission is to balance all project constraints throughout a project life cycle while facilitating, integrating, and guiding the team to be able to deliver within those constraints. Functional AreasThe Program Management advocacy group consists of several functional areas, including Project Management, Program Management, Resource Management, Process Assurance, Project Quality Management, and Project Operations. Project Management (PjM)Project Management ensures that a project team works together to deliver the right solution at the right time given project constraints, where right is defined in agreement with stakeholders. Close coordination is necessary because what is right is subject to evolve as a project goes along. The scope of this functional area is managing one of potentially many projects needed to deliver a solution. Managing a portfolio of projects is handled by a Program Management functional area, discussed next. Key Responsibilities
Key Activities
Program Management (PgM)A Program Management functional area takes a broader view of managing solutions delivery than a Project Management functional area does. Much like how a Project Management functional area manages delivery of a project, a Program Management functional area manages solution delivery, which involves a broader set of responsibilities and often many projects. It often means working with more stakeholders and therefore involves more stakeholder analysis and coordination. Often this functional area is associated with managing at the enterprise level. A Program Management functional area has the same key activities and responsibilities as a Project Management functional area except that the focus is at a solution level instead of at a project level. The following are additional activities and responsibilities of the Program Management functional area beyond those of the Project Management functional area: Key Responsibilities
Key Activities
Resource ManagementWhen delivering a solution that needs unique skills, has new technology, involves creative thinking, and so forth, people are often the most valuable resource. Getting, blending, and retaining staff on a project can be a full-time job, especially when project staff are made up of customer staff, corporate staff, partner staff, and external consultants. Other project resources that might need to be managed by the Resource Management functional area include facilities, hardware, software, and materials. Key Responsibilities
Key Activities
Process AssuranceWhat was the first thing that came to mind when you saw the words process assurance? Most people think "process police," which is unfortunate. If set up correctly, a Process Assurance functional area ensures that a project team adopts processes that focus on helping them meet their project quality goals, with an emphasis on minimizing issues and expeditiously resolving issues when they do arise. Process assurance can be used to help refine processes, making a team more effective. Because people are sometimes protective of their processes and do not appreciate process refinement, it sometimes helps if Process Assurance has some degree of independence from a project team. This way they have an unbiased, external perspective. An obvious risk of moving them outside a team is that they will be viewed as outsiders and are less likely to be welcomed as refining "our" processes. Key Responsibilities
Key Activities
Project Quality ManagementMuch like how Process Assurance's mission is to improve quality and productivity through better processes, Project Quality Management's mission is to improve quality and productivity through better overall project management. This functional area takes many forms in various organizations. Sometimes it is referred to as a Program Management Office (PMO) and sometimes it is called Program Quality Assurance (PQA). Irrespective of the name, the mission is the same: monitor project health and make improvement recommendations as needed. This team is most often an independent team, so they are able to form an unbiased perspective on how well a project is running. Most often, this team is involved with a project team on a limited basis and performs periodic reviews (e.g., quarterly). Typically, this team focuses on high-risk projects and projects critical to the success of an organization. Key Responsibilities
Key Activities
Project OperationsA Project Operations functional area makes sure that day-to-day logistics and administrative details of running a project are addressed and working smoothly. This is often the least appreciated but most valuable functional area in Program Management. If this functional area is set up and operating efficiently, it should be transparent to most people. Often, this functional area handles updating project plans; progress reporting; management and implementation of the risk, issue, and change control processes; and a number of various other project management activities. Effective Project Operations staff requires a combination of strong administrative capability and attention to detail with sound experience in project planning and scheduling techniques, as well as a good understanding of policies and guidelines. On a larger project, this functional area provides an excellent opportunity to work alongside project managers and build experience needed to direct future projects. Key Responsibilities
Key Activities
Architecture Advocacy GroupThe Architecture Advocacy Group drives solution design(s) and design processes. They provide a vital link between the business side of a solution (as represented by product management in conceptual designs) and the technology side of a solution (as represented by development in detailed implementation designs). Architects act as custodians of the content within the functional specification. A functional specification defines features necessary to satisfy solution requirements. Architects also ensure features are traceable back to requirements (and ultimately to the generation of business value) so that all features support stated requirements. This enables a team to assess the impact of any feature changes on solution value. The Architecture Advocacy Group considers all requirements, constraints, expectations, and anything else that influences or biases a solution. They distill these requirements into design(s) for a solution. A design starts with conceptual ideas and becomes more refined and more detailed until it reaches a point when it can be implemented. An Architecture team might also work with Product Management to map out a solutions road map. Advocates
ConstituencyArchitecture team constituents include the following:
FocusThe Architecture team works with the team to develop a solution definition and conceptual architecture that satisfies the requirements. As part of this effort, the Architecture team provides a sanity check on the feasibility of requirements being defined by Product Management. The Architecture team considers all requirements when designing a solution, not just technology requirements. For example, they consider environmental factors such as the services, systems, and standards with which a solution will interoperate; infrastructure in which it will be deployed; its place in business or a product family; and a road map of future versions. The Architecture group ensures that a deployed solution meets all necessary qualities of service and its business objectives, and that it will be viable in the long term. Quality GoalThe quality goal for the Architecture team is this:
Functional AreasThe Architecture Advocacy Group consists of two functional areas: Solution Architecture and Technical Architecture. Solution ArchitectureA Solution Architecture functional area works with the rest of a team and stakeholders to form a conceptual understanding of a solution. As a solution becomes clearer, solution architects develop a conceptual design with various alternatives that emphasize different constraint trade-offs. As project requirements and constraints stabilize, solution architects work with technical architects (discussed next) to refine a design and add more detail so that it can be implemented. Solution architects should be technically sound, with a broad base of knowledge and experience, and be able to relate to technical issues underlying business needs. Although solution architects might rely on technical architects and a development team for expertise on specific technologies used in a solution, they must be able to grasp the implications of those technical details very rapidly and understand their interrelationships and their impact on an environment into which a solution will be deployed. Solution architects must also be able to discuss those impacts with customer architects to rapidly resolve any conflicts between a proposed solution and an enterprise architecture. Key Responsibilities
Key Activities
Technical ArchitectureA Technical Architecture functional area includes technical specialists who work with a solution architecture team to further refine a design to a level that can be implemented. Usually, technical architects are very skilled in particular areas (e.g., security, databases, or messaging). Technology architects provide input into high-level designs, evaluate and validate technologies, and conduct research to mitigate technology risks early in the development process. In coordination with a solution architect team, at the beginning of a project life cycle this functional area focuses on analyzing the requirements from an implementer's perspective. This functional area contributes to the definition of a vision/scope document by evaluating technical implications of a project for implementation feasibility. They provide guidance on pros and cons of possible implementation approaches, define implementation strategies and implementation architecture, and validate initial technology choices. In this process, this functional area might conduct research, consult with counterparts in the organization or elsewhere, and hold discussions with technology providers. For additional validation, this functional area might develop a limited-functionality prototype to serve as a proof of concept. This is particularly relevant for projects that require use of new technologies or in areas where a project team lacks experience. Key Responsibilities
Key Activities
Development Advocacy GroupThe Development Advocacy Group (also called the Build team) is made up of the primary solution builders (i.e., solution development). They build a solution in adherence to a solution architecture and implementation architecture that, together with a function specification, form the overall specifications of a solution. This advocacy group defines low-level solution details, designs feature implementations, refines estimates required to build those features, builds a solution, and then validates that what was built is consistent with the specifications. It is essential that a team that will be implementing a solution validates the estimates. Too many times this step is overlooked and a project suffers for it. The purpose of this effort is to achieve a higher quality of schedule, ownership of the estimates, and increased accountability for work performance. Advocates
ConstituencyBuild team constituents include the following:
FocusThe Development team focuses on building a solution in accordance with the specification(s) while verifying and refining a solution definition and design. Before building a solution, Development provides input into design and technology selection decisions, as well as constructs functional prototypes to validate decision making and mitigate development risks. Building a solution often means developing the component parts of a solution and integrating these parts into a cohesive whole. Throughout this process, the Development team makes sure a realized solution meets its stated quality goals. Quality GoalThe quality goal for Development is this:
Functional AreasAlthough many functional areas are within the Development Advocacy Group such as Application Development and Infrastructure Deployment functional areas, here are some key responsibilities and key activities that span across all functional areas: Key Responsibilities
Key Activities
Test Advocacy GroupAll solutions have issues. The Test Advocacy Group drives conversations to get the team and stakeholders to reach consensus about which issues matter (i.e., which issues are significant enough to block a solution release). Subsequently, this group measures and monitors solution quality and confirms when a solution has achieved its required quality levels and is ready for release. This group is entrusted to represent solution quality fairly and accurately. They validate whether a solution works as expected from a stakeholder perspective. They define quality metrics and regularly report against them to keep the team and stakeholders abreast of quality trends and statistics. Advocates
ConstituencyTest team constituents include the following:
FocusThe Test advocacy group anticipates, looks for, and reports on any issues that diminish solution quality. To achieve this, the Test team continually assesses the status of solution quality as compared to established quality measures. They continually and thoroughly scrutinize a solution from a functional and systems perspective as opposed to making sure the technical parts work as specified, which is a responsibility of the Development team. In other words, the Development team is responsible for ensuring a solution works as specified. The Test team ensures it works as expected from a business perspective and as a whole (i.e., as a system). Quality GoalThe quality goal for the Test team is this:
Functional AreasLike other advocacy groups, the Test Advocacy Group has many functional areas primarily including functional testing and system testing, described shortly. Consistent with the MSF Governance Model (discussed in the next chapter), these testing functional areas need to plan the tests, build the tests, execute the tests, and report and track test status. Here is a brief explanation of these activities that span across all test functional areas:
Functional TestingFunctional testing focuses on making sure a solution works as expected from a user's perspective after it has been proved in development that solution components work as specified. Typically, test cases for functional testing are designed to be consistent with usage scenarios and process flows. Key Responsibilities
Key Activities
System TestingSystem testing focuses on a solution as a whole as opposed to testing component parts of the solution. System testing can involve many types of testing, including the following:
Key Responsibilities
Key Activities
User Experience Advocacy GroupThe User Experience Advocacy Group ensures a solution is as effective as possible from the perspective of the intended users and that users are sufficiently ready to use a solution effectively. To address this twofold responsibility, the User Experience team works with users to understand them holistically, appreciate subtleties of their needs, and develop an awareness of how best to provide users with the necessary solutions knowledge. This advocacy groups also works with the team to maximize usability from a user's perspective. Advocates
ConstituencyUser Experience team constituents include the following:
FocusThe User Experience Advocacy Group focuses on enhancing all aspects of a solution that involve interaction with users, including training, manuals, support, user interfaces, and solution usability. Quality GoalThe quality goals for the User Experience team are as follows:
Functional AreasThe various aspects of user experience are represented in these functional areas: Accessibility, Internationalization, Technical Support Communications, Training, Usability, and User Interface Design. AccessibilityAn Accessibility functional area focuses on ensuring that a solution is accessible to those with disabilities by driving accessibility concepts and requirements into a design. Accessibility is important for many reasons. Primarily, accessibility is important because a solution must be accessible and usable by all people regardless of their capabilities. A solution that does not account for accessibility falls short of full adoption. Additionally, accessibility compliance often is required to meet government regulations. Key Responsibilities
Key Activities
InternationalizationAn Internationalization functional area ensures the quality and usability of a solution for international markets. An Internationalization functional area is composed of both globalization and localization processes.
Key Responsibilities
Key Activities
Technical Support CommunicationsA Technical Support Communications functional area focuses on development of solution support documentation and systems. Support systems often take the form of online tools. These tools (e.g., online, context-sensitive help) benefit both users and organizations: users benefit because they get responses to issues and questions in a timely and effective manner; organizations benefit because support costs are reduced. Key Responsibilities
Key Activities
TrainingA Training functional area focuses on enhancing user performance by providing skills and knowledge needed to use a solution effectively. Skills and knowledge transfer is achieved by implementing a learning strategy followed by a training plan. The development of a learning strategy can take place within an organization, or it might be outsourced to an organization that specializes in training and development. Regardless of who actually develops a learning strategy, the approach most often consists of the following:
A learning strategy might consist of one or more of the following delivery mechanisms: instructor-led training, technology-delivered training, self-study, or the use of job aids. Many organizations choose a blended approach that adapts to different individual learning styles. Key Responsibilities
Key Activities
UsabilityA Usability functional area drives a design of all user interactions. This group continually provides feedback to the team by measuring and assessing user competency and solution proficiency. They work with specified users to achieve specified high-level goals of effectiveness, efficiency, and satisfaction. Often accompanying these goals is a measure of how intuitive a solution is. Key Responsibilities
Key Activities
User Interface DesignA User Interface Design functional area ensures that graphical elements within a solution are designed appropriately. The major responsibility of this functional area is driving user interface (UI) design. This involves designing the objects that users interact with (and the actions applied to those objects), as well as the major screens in the interface. Key Responsibilities
Key Activities
Release/Operations Advocacy GroupThe Release/Operations Advocacy Group ensures smooth delivery and deployment of a solution. Although solutions discussed in this book are mostly referred to as being delivered and deployed into operations, other destinations are equally applicable such as commercial release of a solution through distribution channels. Irrespective of a solution's destination, this team makes sure a solution smoothly transitions from the Delivery team to the intended caretakers of the solutionreferred to here as the Operations team. To achieve their mission, this team has many logistics and readiness activities to consider and work through. For instance, they need to make sure a solution is compatible and can be integrated with its destination. The Release/Operations Advocacy Group works with the Operations team throughout a solution's life cycle to gather and refine operational requirements and/or constraints to provide back to the team for consideration. They work with the Operations team to help build out the production environment. And through this assistance, they are the most qualified team members to determine whether the Operations team is ready to receive a solution. Too many failed projects result from when a Delivery team builds a "great" solution only for it to be driven into the ground by an ill-prepared Operations team. Advocates
ConstituencyRelease and Operations team constituents include the following:
FocusThe Release/Operations Advocacy Group brings an understanding of operations to a project team, and with that knowledge, they focus on making sure a solution is ready for deployment as well as readying Operations for deployment of a solution where a solution is not just technology but also the supporting activities (e.g., training) and operations material (e.g., manuals). Quality GoalThe quality goal for a Release/Operations team is this:
Functional AreasSolutions are deployed by various means and to various destinations. Irrespective of how and where a solution is deployed, here are a few common functional areas of Release and Operations: Release Management, Delivery Infrastructure, Operations, Build Manager, and Tool Administrator. Release ManagementA Release Management functional area coordinates and manages the rollout of each solution release as defined by the Product Planner functional area. A solution might be deployed to Operations or through commercial distribution channels (e.g., shrink-wrapped products). Although deployment to an Operations data center seems nothing like deployment to commercial channels, the concept of making sure deployment goes smoothly is the same. It involves making sure a solution gets from a project team to intended users; and making sure the end users are ready to be productive. Key Responsibilities
Key Activities
Delivery InfrastructureA Delivery Infrastructure functional area focuses on providing a team with the infrastructure necessary to deliver a solution. This team works closely with the Operations team because some of the delivery infrastructure might need to mirror production and need production-like data. Key Responsibility
Key Activities
OperationsAn Operations functional area represents an organization's Operations team. Because they are the ones to work with Operations to take receipt of a solution, it is up to them to make sure that all aspects of a solution are ready for deployment from deployment and sustainability perspectives. To achieve this, they need to be engaged actively in the full life cycle. Being a liaison to Operations teams, this team vets a solution from an operational perspective. For instance, this team reviews support systems being developed by the Technical Support Communications functional area of the User Experience Advocacy Group. Key Responsibility
Key Activities
Build ManagerA Build Manager functional area focuses on systematically and methodically promoting a solution from a development area, through a test area, and to staging areas in preparation for the Operations team to deploy a solution to production. As part of the set of natural checks and balances built into MSF, this team is an independent verifier of deployment activities, plans, and procedures. Many organizations make the mistake of making a development team responsible for moving a solution from a development environment to a test environment, and likewise, a test team moves a solution from a test environment to a staging environment and to a production environment. Although capable, these teams are too familiar with these activities and are likely to compensate, consciously or subconsciously, for inadequacies of deployment procedures. It is only when an independent functional area with a systems engineer perspective does a solution promotion through these environments will deployment plans and procedures really be vetted sufficiently. Key Responsibility
Key Activities
Tools AdministratorWith more and more emphasis placed on achieving higher productivity and efficiency while reducing costs and handling more complex technology, there is a drive to automate as much of solutions delivery as possible. Although there are obvious benefits, there are costs. Primarily, tools that are more complex are needed for this automation. The resource commitment to administer these tools sometimes exceeds that of a team. In addition, administration of these tools at the level and with the flexibility that are sometimes needed for a team to remain agile necessitates a Tool Administrator role. Beyond the obvious administration activities (e.g., setting up test user accounts and filling test environment databases with test data), other activities include helping a team set up and administer the following tools:
Key Responsibility
Key Activities
SummaryBy now, hopefully you see how each advocacy group performs critical activities with built-in quality checks and balances. Although MSF was designed to be adapted, the core principles behind the Team Model should hold. Table 4-3 summarizes what each group advocates, their quality goals, constituents, and typical functional areas identified in the previous sections.
Another way to summarize the advocacy groups is to understand the degree of internal versus external focus as well as the degree of balance between being business focused versus being technology focused. Figure 4-6 illustrates how each advocacy group maps out across these spectrums. As depicted, each group is both internally and externally focused except for Development and Testing, which are internally focused and insulated from external communications. The relative positions should be obvious except for maybe the Test Advocacy group. Why do you think the Test team is on the "business focus" side of the figure? Most people mistakenly think of the testing team as being the ones responsible to making sure the solution works as specified. This responsibility is actually the responsibility of the Build team. As discussed previously, the Test team performs functional and system testing to verify a solution works from a business user perspective. As such, the Test Advocacy Group is much more business focused than it is technology focused. Figure 4-6. Advocacy groups focus across a technology vs. business spectrum
The figure represents a high-level perspective and offers a few constituents to provide context. Typically, teams have to coordinate with many more external groups, such as quality assurance, finance, and legal. It is important that interfaces with any external groups be explicit and understood. It is also important that development and testing continue to be insulated so that they work effectively without unnecessary disruptions. This does not mean that developers and testers should be isolated from the outside world. Contact with customer organization(s) and with real users is often invaluable to build a customer-focused mindset that MSF teams look to achieve, especially in the earlier, formative stages of a project. Such communications should not, however, replace formal communications because two-way communications would suffer badly as development and testing teams become entrenched during later stages of a project. In addition, it is important to emphasize that, although external coordination through various groups can provide input and recommendations, neither individual team members nor teams as a whole have the authority to change priority or specifics of the project trade-offs, such as features, schedule, and resources. Those changes are at the prerogative of a project customer or sponsor and are implemented by a project team through change control. |