MSF Team Model: Team of Advocates


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 Advocates

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

[1] Some of the natural checks and balances structured within MSF are by their very nature competing. For example, a program management team wants to deliver on time, which sometimes means cutting features. Whereas a product management team wants to add as much value to a solution as possible, which sometimes means adding features. More often than not, these are competing goals.

Table 4-1. MSF Advocacy Groups and Their Respective Advocacies

MSF Advocacy Group

Advocates for

Product Management

Solution definition: Solution description optimally satisfies stakeholder needs and expectations.

Program Management

Solution delivery: Project governance optimally satisfies sponsor(s) needs and expectations.

Architecture

Solution design: Solution design optimally satisfies all needs and expectations.

Development

Solution construction: Solution optimally satisfies design.

Solution verification: Solution works as specified.

Test

Solution validation: Solution works as expected.

User Experience

Solution usability: Solution is fit for use and provides an effective, productive, and efficient user experience.

User readiness: Users are sufficiently prepared to use the solution.

Release/Operations

Solution deployment: Solution is smoothly deployed and optimally integrated into its target environment(s).


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:

  • Quality goals

  • Constituents

  • Functional areas

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 Champions

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

Table 4-2. Key Quality Goals and MSF Team Model Advocacy Groups

Key Quality Goals

MSF Advocacy Group

Satisfied stakeholders

Define solution within project constraints

Product Management

Coordinate identification and optimization of project constraints

Deliver solution within project constraints

Program Management

Design solution within project constraints

Architecture

Build solution to specifications

Development

Confirm all aspects of a solution meet or exceed their respective, defined quality levels

Test

Maximize solution usability

Enhance user readiness and effectiveness

User Experience

Smooth deployment and transition to operations

Release/Operations


Satisfied Stakeholders

To 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 Constraints

As 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 Constraints

As 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 Constraints

These 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 Constraints

A 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 Specification

Solution 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 Levels

All 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 Usability

The 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 Effectiveness

A 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 Operations

Often, 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 Ambassadors

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

Clarity Point

Constituents are people or groups of people. The inanimate things that advocacy groups advocate for are called advocacies. For example, the User Experience Advocacy Group advocates for solution usability. Said the other way, solution usability is an advocacy of the User Experience Advocacy Group.


Functional Areas: Team of Representatives

A 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 Teaming

The following are the MSF foundational principles applied to the MSF Team Model.

Foster Open Communications

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

Lesson Learned

To try to achieve open communications, some teams invite the whole team to status meetings such that everyone can hear each other's status firsthand. This is often counterproductive and does not achieve the intended goal. Most subteam members have too-detailed status for it to be of interest to others. Plus, it usually takes a very long time to go around the room soliciting status from everyone. When the project has subteams, a more effective strategy might be to have each subteam conduct their status meeting followed by a team-lead status meeting, or vice versa. This way, only the cross-team-relevant status is raised at the project team lead meeting.

When there is a need for very close coordination, try a daily, first-thing-in-the-morning "stand-up" meeting (i.e., the meeting is so short that people do not have time to sit down). This is a quick sync-up of only the pressing issues for that day. If there is nothing to share, the meeting is over in minutes. The meeting should be time-boxed to no more than a half hour.


Work Toward a Shared Vision

Establishing 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 Members

The 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 Responsibility

Everyone 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 Value

Although 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 Change

One 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 Quality

Breaking 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 Experiences

Setting 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 Customers

The 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 Fundamentals

Before 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 Areas

It 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 Represented

Although 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 Chart

One 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 Points

Many 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 Discipline

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

[2] Project Management Institute, Project Management Body of Knowledge (PMBOK) Guide, 3rd ed. (Newtown Square, PA: Project Management Institute, 2004), sec. 1.3.

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:

  • Communications Plan How, when, and what information to share with various stakeholders and with the team

  • Roles and Responsibilities Who does what, how they fit into a team structure, and what their responsibilities are

  • Integrated Master Schedule A consolidated set of activities (e.g., work breakdown structure (WBS)) with assigned resources (e.g., Resource Assignment Matrix)

  • Staffing Plan How to assess required skills and abilities to identify and recruit personnel needed to deliver a solution

  • Readiness Plan How to bring team member knowledge, skills, and abilities to levels required to perform the assigned roles

  • Risk and Issue Management Plan How to handle risks and issues as they arise

  • Configuration Management Plan How to handle changes to a solution as it is incrementally built and deployed

  • Change Management Plan How to handle changes to the negotiated agreement on project scope, cost, and assigned resources

  • Quality Management Plan How to measure and assess achievement of quality goals

  • Test Plan How to approach making sure a solution not only adheres to the requirements but also that the requirements are what are needed and expected

  • Pilot Plan How to validate a solution through limited-release usage

  • Training Plan How to bring user readiness up to necessary levels

  • Deployment Management Plan How to deploy a solution to its destination(s)

  • Change Enablement Plan How to adapt business processes to realize the full potential of a deployed solution

  • Knowledge Management Plan How to capture and harvest lessons learned while delivering a solution

  • Disaster Recovery Plan How to handle worst-case scenarios that might significantly affect delivering a solution

  • Purchasing and Facilities Plan How to acquire the necessary resources to deliver and deploy a solution

  • Security Plan How to identify security requirements and make sure a solution meets those requirements as well as any security policies

  • Integration Management Plan How to integrate the parts of a solution and integrate a solution into a deployment destination

  • Performance Management Plan How to assess whether value is being realized (e.g., cost performance or schedule earned value analysis [EVA])

  • Capacity Plan How to make sure a solution handles planned growth

  • Budget Plan How to deliver a solution within financial constraints and forecasting future financial needs

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 Group

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

Advocates

Solution definition

Constituency

Product Management team constituents include the following:

  • Stakeholders Anyone with a vested interest in the effort and therefore who might have requirements of a solution, including the following:

    • Project sponsor(s): Initiates, funds, and approves a solution delivery effort

    • Customer(s) (also known as business sponsors): Takes receipt of a solution and expects to gain business value from it

    • User(s): Interacts with a solution

    • Operations team: Hosts, maintains, and administers a solution

  • Internal advisory, regulatory, and/or standards group(s) Requires, mandates, or influences requirements, such as a technology advisory council

  • External advisory, regulatory, and/or standards group(s) Requires, mandates, or influences requirements, such as government regulatory agencies

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 Goals

The quality goals for Product Management are the following:

  • Satisfy stakeholders

  • Define solution within project constraints

Focus

Product 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 Areas

The Product Management Advocacy Group consists of several functional areas, including Marketing/Corporate Communications, Business Analyst, and Product Planning.

Clarity Point

It is expected that some organizations may have different names for their functional areas for this and the other advocacy groups. Some functional areas may not exist within an organization. However, the key is that all responsibilities and activities identified for the various advocacy groups need to be advocated regardless of how a project team is structured.


Marketing/Corporate Communications

Before 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 Responsibilities

This functional area and the others to follow have key responsibilities. Key responsibilities for this functional area include the following:

  • Marketing and public relations messages to excite and positively affect the target customer and users

  • Understanding the competitive landscape

  • Distribution channels so target customers easily acquire a solution

  • For packaged solutions, enabling customers to have a positive experience buying and using a solution

Key Activities

Each 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:

  • Develop a plan to promote a solution

  • Be able to highly differentiate a solution so it stands out from the competition

  • Set up and prepare distribution channels

Business Analyst

A 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
  • Solution landscape

  • Stakeholder expectations

  • Quantifying a solution's return on investment (ROI)

  • Sponsor relationship

Key Activities
  • Perform objective cost/benefit analyses to help communicate to the team a defined stack ranking of requirements and feature priority

  • Assist sponsor's development of a business case

  • Define and maintain business justification for a project

  • Define and measure business value realization and metrics

  • Manage customer expectations and communications

  • Determine business metrics and success criteria

  • Provide requirements and feature trade-off decisions

Product Planning

As 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
  • Shared project and solution vision

  • Working with the respective teams to deliver a solution version consistent with a solution road map

  • Being the authority on requirements and expectations associated with each release

  • Solution definition and solution definition process

Key Activities
  • Stack-rank requirements and features for a solution and for each release

  • Balance and trade off requirements with project(s) constraints

  • Perform market research, market demand, competitive intelligence/analysis

  • Gather, analyze, and prioritize customer and business requirements

  • Perform release-level requirements and feature trade-off decisions

  • Identify a multiversion release plan

Program Management Advocacy Group

The 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
  • Solution delivery

Constituency

Program Management team constituents include the following:

  • Project sponsors[3] Initiates, funds, and approves a project and its deliverables

    [3] Project Management and Product Management have a different relationship with project sponsor(s). Project Management focuses on project governance and constraints (e.g., money), whereas Product Management focuses on solution definition.

  • Internal governance group(s) Requires, mandates, or influences project management practices such as Program Management Office (PMO)

  • External governance group(s) Requires, mandates, or influences project management practices such as government regulatory agencies

Quality Goals

The quality goals for Program Management are as follows:

  • Coordinate identification and optimization of project constraints

  • Deliver solution within project constraints

Focus

Program 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 Areas

The 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
  • Completely understanding project constraints and high-level requirements, and how they are allocated across the advocacy groups

  • Delivering a solution that best balances project constraints

  • Risk and issue management process (project level)

  • A functional specification that meets project constraints

  • Project Management Plan with its various subordinate plans (e.g., Deployment Management Plan)

Key Activities
  • Work with the other project leads to organize project teams, sometimes referred to as work streams or swim lanes, into groupings that make sense given what needs to be done (discussed in more detail later)

  • Work with architects and team leads to create a WBS

  • Work with architects and team leads to staff and resource plans

  • As the owner of the schedule, integrate and validate all team schedules into a master project schedule that is tracked and reported to the team and project stakeholders

  • Manage master project schedule

  • Manage functional specification and definition of the constraints portion of a functional specification

  • As the owner of a project budget, facilitate the creation of a project budget by gathering and validating resource requirements (hardware, software, and people)

  • Track and manage project budget

  • Facilitate communication and negotiation within a team

  • Track progress and manage project status reporting

  • Manage resource allocation (project level)

  • Manage project change control

  • Drive critical project decisions

  • Facilitate project-relevant communication

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
  • Completely understanding solution constraints and high-level requirements, and how they are allocated across projects within the program

  • Portfolio of projects and how to best deliver a solution

  • Program Management Plan with its various subordinate plans that span across the various projects

Key Activities
  • Work with project leads to coordinate and synchronize work, dependencies, and deliverables

  • Work with solution architects to create and decompose solution delivery across multiple projects

Resource Management

When 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
  • Completely understanding and optimally satisfying the resource needs of each project

  • Skills readiness

  • Furnishing a range of staffing resource (e.g., vendor, consultants, partners)

Key Activities
  • Understand needed skill profiles and match them up with available resources

  • Help define skill profile(s) to use for estimating, and, as staff are identified, normalize project activity estimates given staff availability and assessed capabilities

  • Efficiently recruit team members

  • Once candidate resources are identified, work with the respective team leads to vet the resources

  • Assist team leads with skills readiness analysis

  • Assist with team member skills improvement

  • Work with external and internal staffing providers to secure project staff

  • Understand team chemistry and team dynamics to blend assigned staff optimally

Process Assurance

What 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
  • Process quality assurance

  • Determining the team's tolerance to quality processes

Key Activities
  • Understand team capabilities and abilities as well as the quality and project goals to define processes that enable and increase team quality and productivity through process definition, education, and refinement

  • Provide advice and guidance on effective implementation of project processes; validate compliance with processes; undertake checkpoint reviews; recommend process improvements

  • Undertake reviews to validate relevance and effectiveness of each process, recommending improvements and monitoring compliance

  • Drive process enablement through tool selection and implementation

Project Quality Management

Much 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
  • Independent validation of project health and project risks within an organization project portfolio

  • Quality control

  • Quality metrics

Key Activities
  • Proactively monitor project health and recommend improvements as needed

  • Help harvest lessons learned

  • Help identify and mitigate project risks

  • Conduct periodic reviews of program management practices

  • Review risk and change management processes and practices

  • Define and report on program-wide quality metrics

  • Assist Program Management team as a sounding board

Project Operations

A 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
  • Project management processes and support for team leads in using them

  • Program/project operations

Key Activities
  • Ensure that a project team operates effectively with the minimum of bureaucracy

  • Support project initiation processes, such as drafting a new team member orientation guide; manage contractual arrangements; organize team facilities (e.g., space, telephones, security access, and computer accounts)

  • Establish consistent planning framework; assist team leads in planning and scheduling; consolidate team input to create master plan and schedule; establish financial and progress reporting processes

  • Assist team leads in progress reporting; create overall progress and financial reports; update and manage master schedule

  • Perform general administrative support activities: scheduling meetings; implementing risk and issue management processes; maintaining the master risk list, action list, and issue list; generating financial and progress reports; and managing team location to enhance morale

  • Gather actuals and compare to schedule to calibrate remaining estimates

  • Administer project planning tools (e.g., Microsoft Project Server)

  • Ensure closure of all administrative systems on project completion

Architecture Advocacy Group

The 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
  • Solution design

Constituency

Architecture team constituents include the following:

  • Team members building a solution according to their designs

  • Other teams delivering a different portion of a solution (when a project is part of a program)

  • Internal advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solution designs, such as an enterprise architecture group

  • External advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solution designs, such as a security standards consortium

Focus

The 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 Goal

The quality goal for the Architecture team is this:

  • Design a solution within project constraints

Functional Areas

The Architecture Advocacy Group consists of two functional areas: Solution Architecture and Technical Architecture.

Solution Architecture

A 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
  • Ensuring a solution can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction

  • Overall solution architecture and its positioning within an enterprise architecture

  • Solution definition portion of a functional specification

  • High-level, top-down estimates for solution components

  • Solution scope and critical trade-off decisions

  • Qualities of service (e.g., design for the "ilities")

  • Major business-driven checkpoints and tasks

  • Solutions road map

Key Activities
  • Define conceptual solution and conceptual design, and align them with an enterprise architecture; work with technical architects to refine them into detailed implementation designs

  • Review and execute plans to harvest requirements from architectural and standards groups related to interoperability; drive design process; provide a traceability map tracing features back to requirements and benefits

  • Update requirements for future versioned releases; devise versioned release strategy; and define interim releases

  • Create and manage changes to the technology portions of a high-level functional specification; maintain traceability map; clarify specifications to other team roles and to external stakeholders; liaise with other project teams on interoperability issues

  • Participate in triage process; manage project stakeholder expectations regarding solution content

  • Work with and provide updates to Enterprise Architecture team

  • Help validate solution

  • Work with Product Management to help quantify business value and "sell" (emphasize) the merits of a solution

  • Work with Operations to design in necessary qualities of service (QoS)

  • Help design for reusability (e.g., design a service-oriented architecture)

  • Provide initial top-down estimates to help initial planning

  • Drive high-level work breakdown structure (WBS)

  • Drive high-level, top-down estimates for solution components

Technical Architecture

A 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
  • Solution implementation design

  • Detailed functional specification (also called a technical specification) and bottom-up estimates

  • Implementation architecture

  • Major implementation-driven checkpoints and tasks

Key Activities
  • Validate major business-driven checkpoints and tasks

  • Decompose solutions architecture into tangible, implementable components and tasks (leaving the detailed implementation decisions for a build team)

  • Map the enterprise architecture to a solution's implementation architecture by providing solution-specific detail for application, data, and technology views of a solution

  • Develop high-level, top-down estimates given design details and calibrated team member skills

  • Expand WBS details

  • Evaluate and validate technologies

  • Contribute to defining technology standards for an organization

  • Work with PjM on resource planning and balancing workload

  • Validate top-down, high-level estimates by comparing bottom-up estimates developed when adding more design details

  • Validate and quantify technology risks

Development Advocacy Group

The 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
  • Solution construction

  • Solution verification

Constituency

Build team constituents include the following:

  • Internal advisory and/or standards group(s) Requires, mandates, or influences solution implementation, such as an enterprise coding standards group

  • External advisory and/or standards group(s) Requires, mandates, or influences solution implementation, such as the Extensible Markup Language (XML) standards body

Focus

The 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 Goal

The quality goal for Development is this:

  • Build solution to specifications

Functional Areas

Although 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
  • Detailed implementation designs

  • Thoughtful technical decisions

  • Clean implementations

  • Validation and adoption of estimates

  • Right quality solution

  • A means for others to verify proper implementation (e.g., unit tests)

Key Activities
  • Review implementation architecture

  • Develop detailed implementation designs

  • Develop features that meet design specifications

  • Carry out technical testing (as opposed to functional testing and system testing, discussed later) as defined in a test plan to ensure a solution works according to its specifications

  • Develop automated deployment mechanism

  • Develop deployment documentation

  • Decompose major checkpoints and tasks into actionable tasks

  • Validate major implementation-driven checkpoints and tasks

  • Address quality issues identified in a testing process

  • Carry out integration of solution components to produce final deliverable

  • Contribute to the definition of standards and adhere to these during solution development

  • Conduct reviews to share knowledge and experience as well as to assess the quality level of solution components and features at an implementation level

Test Advocacy Group

All 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
  • Solution validation

Constituency

Test team constituents include the following:

  • Project sponsor(s) Initiates, funds, and approves a solution delivery effort

  • Customer(s) (also known as business sponsors) Has needs and expectations that a solution must satisfy

  • Internal advisory and/or standards group(s) Requires, mandates, or influences solution validation, such as an enterprise quality metrics standards group

  • External advisory and/or standards group(s) Requires, mandates, or influences solution validation, such as the ISO 20000 IT Service Management Standards

Focus

The 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 Goal

The quality goal for the Test team is this:

  • Confirm all aspects of a solution meet or exceed their respective, defined quality levels

Functional Areas

Like 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:

  • Test planning How a team ensures that all solution quality issues are identified and those that matter are addressed. The Test team develops testing approaches and plans, and by doing so outlines a strategy a team will use to test a solution. These plans include specific types of tests, specific areas to be tested, test success criteria, and information on resources (both hardware and people) required to test. Specific activities include the following:

    • Develop testing approach and plan

    • Define test data requirements

    • Develop test harnesses (i.e., automated means to test solution components)

    • Participate in setting the quality bar by providing input to a project team on quality control measures and criteria for success of a solution

    • Develop a test specification, a detailed description of tools and code necessary to meet the needs defined in a test plan

  • Test engineering Carry out activities defined in test planning. Specific activities include the following:

    • Conduct tests to accurately determine status of solution quality

    • Develop, test, and maintain test cases, tools, and scripts

    • Develop and maintain tools, scripts, and documentation to perform testing functions

    • Ensure that test procedures are performed and reported within a single frame of reference

    • Conduct tests to accurately determine the status of solution quality

    • Identify and surface issues

    • Lead the issue triage effort

  • Tracking and reporting Articulate clearly to a project team the current solution quality assessment. Issue tracking is performed to ensure that all identified issues of concern have been resolved before solution release. Specific activities include the following:

    • Assess quality as it relates to the quality measures

    • Provide team with data related to solutions quality

    • Track and communicate issues to ensure their resolution before solution release

Functional Testing

Functional 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
  • Ensuring that a solution functionally works as expected from a user's perspective (i.e., a business perspective, not a technical perspective)

  • Ensuring that a solution functionally flows smoothly from a process-flow perspective

Key Activities
  • Perform positive testing (using data within expected ranges) as well as negative testing (using data outside of expected norms). For instance, if an input field expects a value between 1 and 10, positive testing might try entering a 5 whereas negative testing might try 25 or the letter a to see what happens.

  • Define and gather (maybe develop) test data to perform their tests.

  • Define and develop test harnesses to perform tests.

  • Define and develop test cases using the selected testing tool (e.g., automated test tool, manual test scripts).

System Testing

System 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:

  • Integration testing Testing to see whether component parts work well together and a solution works with other solutions and legacy systems as expected

  • Performance testing Performing tests and comparing timed performance tests of major components and a solution as a whole to expected design performance requirements. For instance, expected designed performance might be that a Web service takes 0.1 seconds to handle a request, transaction management takes 0.3 seconds to process the request, database management takes 0.3 seconds to execute the query and pass back the data, transaction management takes 0.1 seconds to package up the response, and the Web service takes 0.05 seconds to send out the response.

  • Environmental testing Testing whether a solution operates as expected in its deployed environment. This type of testing can include ambient testing that varies with temperature, power, and moisture. It also might test that power, space, and memory consumption are within acceptable parameters.

Key Responsibilities
  • Ensuring that a solution works as expected and as specified from a holistic perspective

  • Ensuring that a solution works in the environment(s) in which it will be deployed

Key Activities
  • Perform positive and negative testing

  • Define and gather (maybe develop) test data to perform tests

  • Define and develop test harnesses to perform tests

  • Define and develop test cases using the selected testing tool (e.g., automated test tool, manual test scripts)

User Experience Advocacy Group

The 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
  • Solution usability

  • User readiness

Constituency

User Experience team constituents include the following:

  • User(s) Individuals and/or systems that interact with a solution

  • Operations support team Individuals and/or systems that provide operations support to users

  • Internal advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solutionhuman interactions, such as a human factors group

  • External advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solutionhuman interactions, such as the Americans with Disabilities Act

Focus

The 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 Goal

The quality goals for the User Experience team are as follows:

  • Maximize solution usability

  • Enhance user readiness and effectiveness

Functional Areas

The various aspects of user experience are represented in these functional areas: Accessibility, Internationalization, Technical Support Communications, Training, Usability, and User Interface Design.

Accessibility

An 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
  • Driving accessibility concepts and requirements into a design

  • Validation of solution accessibility with constituents

Key Activities
  • Incorporate an accessibility section within each feature specification

  • Integrate accessibility information into a solution help section

  • Set up and conduct evaluation sessions with constituents

  • Gather and distill evaluation feedback and provide it to the team

  • Ensure accessibility documentation is complete and presented in accessible formats

Internationalization

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

  • Globalization Process of defining and building a solution that takes into account the need to localize a solution and its content without modification or unnecessary workarounds by the localizers. In other words, a released solution that is globalized properly is ready to be localized with a minimum of difficulty.

  • Localization Involves modifying a solution's user interface, help files, printed and online documentation, marketing materials, and Web sites. Occasionally, these materials require changes in graphical elements for a particular language version or even content modifications.

Key Responsibilities
  • Quality and usability of a solution in international markets

  • Validation of solution internationalization with constituents

Key Activities
  • Ensure user interfaces are encoded to support localization (e.g., not hard coded)

  • Set up and conduct evaluation sessions with constituents

  • Gather and distill evaluation feedback and provide it to the team

Technical Support Communications

A 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
  • Timely and sufficient technical support collateral and systems to maximize user effectiveness and productivity

  • Validation of solution support effectiveness with constituents

Key Activities
  • Design and develop support documentation for a solution, including development of installation, upgrade, and troubleshooting guides; help desk and operations manuals; help; knowledge base articles and whitepapers; and online chat support services

  • Create tools to empower users to quickly resolve their own issues by providing answers to basic questions, keyword descriptions, error explanations, and frequently asked questions

  • Provide help: online, context sensitive, written, and chat

  • Set up and conduct evaluation sessions with constituents

  • Gather and distill evaluation feedback and provide it to the team

Training

A 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:

  • Assessing current user capabilities

  • Understanding organizational goals and objectives

  • Establishing desired skill levels

  • Developing and implementing a training plan

  • Upon implementation, measuring training effectiveness and modifying the training plan as appropriate

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
  • Ensuring users have sufficient skills and knowledge to use a solution effectively

  • Validation of solution training with constituents

Key Activities
  • Develop and execute learning strategy (build/buy/deliver)

  • Assess optimal delivery mechanism(s)

  • Set up and conduct training pilot sessions

  • Gather and distill pilot feedback and provide it to a team

Usability

A 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
  • Driving usability into a design

  • Validation of solution usability with constituents

Key Activities
  • Conduct usability research, which includes gathering, analyzing, and prioritizing user requirements. When time is invested early on and throughout a solution development effort to understand users, a project has a much higher likelihood of effectively meeting the needs of users.

  • Assist Product Management in development of usage scenarios and use cases with a focus on usability. The key idea here is to step back and look at how an entire solution likely will be used. This effort helps the Development team understand how a user is likely to approach a solution from a conceptual and literal standpoint and often leads to design improvements that result in increased efficiency.

  • Continually assess usability by providing feedback to the team and input to a solution. When the Usability group takes the time to provide user feedback to developers throughout a development cycle, a solution benefits by achieving a higher rate of user satisfaction.

  • Assess and reengineer solution process flows (e.g., through listening labs) to maximize usability.

  • Assist Product Management in user acceptance testing (UAT).

  • Set up and conduct usability evaluation sessions with constituents.

  • Gather and distill evaluation feedback and provide it to the team.

User Interface Design

A 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
  • Driving human factors best practices into a design

  • Driving user interface design

  • Validation of solution user interface design with constituents

Key Activities
  • Develop a wire-frame user interface to help validate the UI design and process flow as well as to act as a visual specification

  • Set up and conduct usability evaluation sessions with constituents

  • Gather and distill evaluation feedback and provide it to the team

Release/Operations Advocacy Group

The 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
  • Solution deployment

Constituency

Release and Operations team constituents include the following:

  • Operations team Hosts, maintains, and administers a solution

  • Internal advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solution operations, such as a capacity planning group

  • External advisory, regulatory, and/or standards group(s) Requires, mandates, or influences solution operations, such as the IT Infrastructure Library (ITIL) guidelines

Focus

The 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 Goal

The quality goal for a Release/Operations team is this:

  • Smooth deployment and transition to operations

Functional Areas

Solutions 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 Management

A 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
  • Evaluating release readiness

  • Handling all logistics associated with the release to Operations or media control

  • Commercial release management

    • Product registration codes; registration verification process

    • Licensing management

    • Packaging

    • Managing distribution channel(s)

    • Print and electronic publication

Key Activities
  • Certify release candidates for shipment or deployment

  • Work with Operations to prepare for the release

Delivery Infrastructure

A 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
  • Building and administering the infrastructure necessary (e.g., environments such as development, testing, staging, training, research) for the various solution delivery activities

Key Activities
  • Build and administer support infrastructure for pilot deployment(s) and user acceptance testing

  • Provide infrastructure services to a team (e.g., building servers, standard images, installing software)

  • Set up and administer account and system setup controls as well as user accounts and permissions used by a team

  • Assist in hardware/software procurement

  • Rack and stack lab equipment

  • Retrieve and administer a snapshot of operations data to use for development, testing, and training

Operations

An 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
  • Ensuring solution being built and deployed is operable and compatible with other services in operations

  • Ensuring solution built and deployed is operationally supportable

Key Activities
  • Plan and manage solution deployment into production

    • Messaging, database, telecom, and network operations

    • Systems administration, batch processing

    • Firewall management, security administration

    • Application services

    • Host integration services

    • Directory service operations

  • Set operations acceptance criteria for release to production

  • Participate in design, focusing on qualities of service (e.g., manageability, availability, supportability, and deployability)

  • Assist the training team in defining requirements for and execution of training for operations

  • Ensure stabilization measurements meet acceptance criteria

  • Provide a team with policies and procedures for consistent infrastructure management and standards

  • Coordinate physical environment use and planning across geographies (data centers, labs, field offices)

  • Help develop and validate "as-built" documents

  • Provide primary liaison and customer service to users

  • Support the business by managing the Service Level Agreement (SLA) with the customer and ensuring commitments are met

  • Provide incident and problem resolution; rapid response to user requests and logged incidents

  • Give feedback to build and design teams

  • Assist with capacity planning

  • Develop failover and recovery plans and procedures

Build Manager

A 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
  • Maturing and verifying deployment processes and procedures

Key Activities
  • Manage tool selection for release activities and drive automation optimization

  • Back up and archive collateral

Tools Administrator

With 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:

  • Issue tracking tools

  • Design, build, and test tools

  • User feedback and survey tools

  • Test environment refresh tools

Key Responsibility
  • Defining and administering tools necessary to support delivery of a solution

Key Activities
  • Administer users

  • Build and maintain tools

  • Integrate tools to provide consolidated status

  • Create procedures to refresh testing systems after testing sessions

Summary

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

Table 4-3. Summary of Advocacy Group Attributes

Advocacy Group

Advocates

Quality Goals

Constituents

Functional Areas

Product Management

Solution definition

Satisfy stakeholders

Define solution within project constraints

Stakeholders

Internal advisory, regulatory, and/or standards group(s)

External advisory, regulatory, and/or standards group(s)

Marketing/Corporate Communications

Business Analyst

Product Planning

Program Management

Solution delivery

Coordinate identification and optimization of project constraints

Deliver solution within project constraints

Project sponsor(s)

Internal governance group(s)

External governance group(s)

Project Management

Program Management

Resource Management

Process Assurance

Project Quality Management

Project Operations

Architecture

Solution design

Design a solution within project constraints

Other teams delivering a different portion of a solution

Team members building a solution according to their designs

Internal advisory, regulatory, and/or standards group(s)

External advisory, regulatory, and/or standards group(s)

Solution Architecture

Technical Architecture

Development

Solution construction

Solution verification

Build solution to specifications

Internal advisory and/or standards group(s)

External advisory and/or standards group(s)

 

Test

Solution validation

Confirm all aspects of a solution meet or exceed their respective, defined quality levels

Project sponsor(s)

Customer(s)

Internal advisory and/or standards group(s)

External advisory and/or standards group(s)

Functional Testing

System Testing

User Experience

Solution usability

User readiness

Maximize solution usability

Enhance user readiness and effectiveness

Users Operations Support team

Internal advisory, regulatory, and/or standards group(s)

External advisory, regulatory, and/or standards group(s)

Accessibility

Internationalization

Technical Support Communications

Training

Usability

User Interface Design

Release/Operations

Solution deployment

Smooth deployment and transition to operations

Operations team

Internal advisory, regulatory, and/or standards group(s)

External advisory, regulatory, and/or standards group(s)

Release Management

Delivery Infrastructure

Operations

Build Manager

Tool Administrator


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.




MicrosoftR Solutions Framework Essentials. Building Successful Technology Solutions
Microsoft Solutions Framework Essentials: Building Successful Technology Solutions
ISBN: 0735623538
EAN: 2147483647
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net