What is the best division of labor when a team is trying to deliver solutions? How does a team make sure it represents the interest of all stakeholders sufficiently? How should a team be structured to facilitate being a high-performing team? How should a team be organized to work naturally toward quality goals? As you well know, many factors influence how to structure a team. Over the years, Microsoft has experimented with various teaming models. What has worked best has been distilled into the following concepts surrounding teaming. The next few sections map how these concepts relate to the Microsoft Solutions Framework (MSF) foundational principles, mindsets, and proven practices.
This chapter describes a scalable and extensible teaming strategy developed, refined, and validated over many years. It represents not only a means to organize a team to represent stakeholder interests but embeds a set of natural checks and balances to help increase quality and minimize bureaucracy. It embodies the MSF foundational principles and incorporates core disciplines and key concepts.
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.
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).
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). |
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:
Constituents
The following sections discuss these aspects and how roles relate to advocacy groups, and then provide an in-depth discussion of each advocacy group.
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
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 |
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.
As discussed in Chapter 2, 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.
As discussed in Chapter 7, 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.
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.
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, designing a solution involves a gradual evolution from high-level, conceptual designs to low-level, implementation designs.
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.
All solutions have issues. However, as discussed in Chapter 10, 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."
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.
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.
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.
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.
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.
The following are the MSF foundational principles applied to the MSF Team Model.
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).
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.
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.
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 together—unlike other models where the overall manager is responsible.
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.
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 themselves—including 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.
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.
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.
The MSF team roles are set up to maximize coordination with customers—each 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.
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.
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.
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 person—multiple 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.
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.
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.
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).
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.
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.
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.
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.
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.
The quality goals for Product Management are the following:
Satisfy stakeholders
Define solution within project constraints
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 happens—no 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.
The Product Management Advocacy Group consists of several functional areas, including Marketing/Corporate Communications, Business Analyst, and Product Planning.
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.
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
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
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.
Solution landscape
Stakeholder expectations
Quantifying a solution’s return on investment (ROI)
Sponsor relationship
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
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.
As discussed in Chapter 6, 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.
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
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
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. 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 worries—this is discussed in more detail in subsequent chapters.
Program Management team constituents include the following:
Project sponsors[3]. Initiates, funds, and approves a project and its deliverables
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
The quality goals for Program Management are as follows:
Coordinate identification and optimization of project constraints
Deliver solution within project constraints
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.
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 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.
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)
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)
Drive critical project decisions
Facilitate project-relevant communication
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:
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
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.
Completely understanding and optimally satisfying the resource needs of each project
Skills readiness
Furnishing a range of staffing resource (e.g., vendor, consultants, partners)
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
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.
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
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.
Independent validation of project health and project risks within an organization project portfolio
Quality control
Quality metrics
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
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.
Project management processes and support for team leads in using them
Program/project operations
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
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.
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
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.
The quality goal for the Architecture team is this:
Design a solution within project constraints
The Architecture Advocacy Group consists of two functional areas: Solution Architecture and Technical 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.
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
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
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.
Solution implementation design
Detailed functional specification (also called a technical specification) and bottom-up estimates
Implementation architecture
Major implementation-driven checkpoints and tasks
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
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.
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
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.
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:
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)
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
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.
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
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).
The quality goal for the Test team is this:
Confirm all aspects of a solution meet or exceed their respective, defined quality levels
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 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.
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 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.
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
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.
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 solution–human interactions, such as a human factors group
External advisory, regulatory, and/or standards group(s). Requires, mandates, or influences solution–human interactions, such as the Americans with Disabilities Act
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.
The quality goals for the User Experience team are as follows:
Maximize solution usability
Enhance user readiness and effectiveness
The various aspects of user experience are represented in these functional areas: Accessibility, Internationalization, Technical Support Communications, Training, Usability, and User Interface Design.
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.
Driving accessibility concepts and requirements into a design
Validation of solution accessibility with constituents
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
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.
Quality and usability of a solution in international markets
Validation of solution internationalization with constituents
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.
Timely and sufficient technical support collateral and systems to maximize user effectiveness and productivity
Validation of solution support effectiveness with constituents
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
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.
Ensuring users have sufficient skills and knowledge to use a solution effectively
Validation of solution training with constituents
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.
Driving usability into a design
Validation of solution usability with constituents
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.
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.
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 solution—referred 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.
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
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).
The quality goal for a Release/Operations team is this:
Smooth deployment and transition to operations
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.
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.
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
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.
Building and administering the infrastructure necessary (e.g., environments such as development, testing, staging, training, research) for the various solution delivery 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
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.
Ensuring solution being built and deployed is operable and compatible with other services in operations
Ensuring solution built and deployed is operationally supportable
Plan and manage solution deployment into production
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
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.
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
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.
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.
[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.
[2] Project Management Institute, Project Management Body of Knowledge (PMBOK) Guide, 3rd ed. (Newtown Square, PA: Project Management Institute, 2004), sec. 1.3.
[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.
13.59.141.75