Adapting Team Size to Project Size

For project teams, at least one person is usually assigned to each role to ensure that someone looks after that role's interests. The greatest challenge with large-scale projects is setting up and maintaining effective communication. For smaller projects or in smaller organizations, the same person may be assigned to multiple roles. In that case, the greatest challenge is to successfully wear multiple hats and to ensure that all the issues are looked at with each hat.

Large-Project Scaling

In his book Rapid Development (Microsoft Press, 1996), former Microsoft software developer Steve McConnell states:

Large projects call for organizational practices that formalize and streamline communication. … All the ways to streamline communication rely on creating some kind of hierarchy; that is, creating small groups, which function as teams, and then appointing representatives from those groups to interact with each other and with management.

To scale large projects, the project team can be divided into two kinds of subteams: feature teams and function teams.

Feature Teams

Feature teams are small subteams that organize one or more members from each role into a matrix organization. These teams are then assigned a particular feature set and are responsible for all aspects of that feature set, including its design and schedule. For example, a feature team might be dedicated to printing.

Steve McConnell writes in Rapid Development:

Feature teams have the advantages of empowerment, accountability, and balance. The team can sensibly be empowered because it contains representatives … from each of the concerned parties. The team will consider all necessary viewpoints in its decisions and thus there will hardly ever be a basis for overriding its decisions.

For the same reason, the team becomes accountable. They have access to all the people they need to make good decisions. If they don't make good decisions, they have no one to blame but themselves. The team is balanced. You wouldn't want development, marketing, or quality assurance alone to have ultimate say over a product's specification, but you can get balanced decisions from a group that includes representatives from each of those categories.

Function Teams

Function teams exist within a role. They arise when a team or project is so large that it requires the people within a role to be grouped into teams based upon their functionality. For example, it is common at Microsoft for a Product Management team to have a Product Planning team and a Product Marketing team. Both jobs form an aspect of Product Management, but one focuses on getting the features the customer really wants and the other focuses on communicating the benefits of the product to potential customers.

As another example, the Development role might need to be grouped by service layer: user, business, or data. It is also common for developers to be grouped based on whether they are solution builders or component builders. Solution builders build enterprise applications by "gluing" together the separate parts of the product produced by the component builders. Solution builders usually work with higher-level languages such as Microsoft Visual Basic, whereas component builders usually work with low-level C code to create reusable components that can be leveraged by the enterprise for multiple projects.

Small-Project Scaling

Although the MSF Development Team Model consists of six roles, a team doesn't need a minimum of six people. In other words, it doesn't require one person per role. The key point is that the six goals have to be represented by the six roles on every team. Having at least one person per role helps to ensure that someone looks after the interests of each role, but not all projects can be approached in that fashion.

On smaller teams, one team member might have more than one role. Two principles guide this type of role sharing:

• Single role for Development Development team members should never be assigned to another role. The developers are the builders, and they should not be distracted from their main task. To give additional roles to the Development team only makes it more likely that schedules will slip due to these other responsibilities.
• Conflict of interest Roles that have intrinsic conflicts of interest should not be combined. For example, Product Management and Program Management have conflicting interests. Product Management wants to satisfy the customer whereas Program Management wants to deliver on time and on budget. If these roles are combined and the customer requests a change, the risk is that either the change will not get the consideration it deserves to maintain customer satisfaction, or that it will be accepted without understanding the impact on the project. Having different team members represent these roles helps to ensure that each perspective receives equal weight.

Figure 3.2 illustrates risky and synergistic combinations of roles. The role combinations marked N should not be combined because of conflicting interests. The role combinations marked U are unlikely combinations, as the skills required for each role differ. For example, the skills and focus of Product Management vary greatly from those of Logistics Management. The role combinations marked P are possible combinations, because they represent compatible interests. For example, Testing and User Education both focus on users and try to ensure that the users' needs are met.

Figure 3.2 Risky and synergistic role combinations

As with any teaming exercise, successful role sharing comes down to the actual team members themselves and what experience and skills they bring to the project. Some projects successfully share roles even though the table indicates a risk. The point is that if a team needs to share roles, the goals of the roles must be kept in mind so that the amount of conflict that could arise because of the role sharing is controlled. Otherwise, some aspect of the key goals might be overlooked, or risks might be in some way mismanaged.