Project Team Size: Smaller is Often Sweeter


How often have you seen managers make a decision–or more likely, fail to make an effective decision–by calling a meeting and inviting lots of people? At least two people from each of several cross functional groups are invited even though that may be redundant. The meeting consists of at least ten people. The meeting is set to discuss a process and the problem is not explicitly defined.

The meeting lasts for sixty or ninety minutes during which time possible strategies are discussed. Others point out the weaknesses and risks of strategies presented by others. The conversation loses focus of the issue at hand several times. At the end of the meeting, the meeting organizer or leader of the functional group responsible states something along the lines of, “This was a good discussion. Let’s meet again next week and discuss further.”

Then next week comes around and, if the leader actually followed through, the meeting reconvenes. Several of the previous week’s attendees are out on vacation or sick leave and others have joined or filled in for those that are missing. The meeting follows the same track as before except that some participants become a little more frustrated than the previous time because of the lack of progress. Many of the same topics and issues are discussed. The meeting ends the same as the previous meeting with the leader noting, “Good discussion. Frank, will you please set up a meeting for next week so we can continue our discussion?”

And so this dismal pattern continues until finally a higher level leader cites a different issue as the most important item for the organization’s focus. Or, the leader that owns the functional group responsible either forgets to set up a new meeting or forgets to assign a team member the task.

Or, in an information technology organization, how often have you observed a company assemble a large group to develop software? Because they are a large group (after all, the projects they will deliver are large projects) they will enjoy efficiencies as a result of economies of scale. But, 18 months later, the group is disbanded when higher level leaders find that the group has not produced any tangible deliverables. I have seen this a few times from both the inside and outside.

Large groups are often inefficient at certain types of work. This flies in the face of what you learned in operations management class where economies of scale associated with large, pooled-resource work groups are the mantra. Six Sigma projects almost always work better with relatively small project teams of between two and four core members. Likewise, many types of software development projects (not necessarily all), even those that seem relatively large, often work better with smaller development teams.

In the example of the strategy meeting above, there are several issues that prevented the group from achieving success. Putting aside things like a lack of agenda, ineffective meeting management, etc., one of the main issues was the size of the group. Why is it that larger groups, which arguably consist of a greater number of skills when you consider each of the participants, seem to have a harder time delivering results?

The problem lies between the people. And I mean more than just communication. Lots of communication, as demonstrated above, does not always result in everyone agreeing on how to improve a process–in fact, larger groups tend to have a wider array of conflicting opinions. It is, therefore, helpful to have a leader that has final decision making authority. Then, if the group is stuck, the leader can take input from each team member and then make a decision for the group.

Communication is also a factor. It is much easier for a smaller group to stay in sync during a project simply because there are fewer people to inform regarding changes. There also tends to be more self-enforcing accountability in a smaller group. If I do some work that creates a problem for the project, I have less chance of hiding or passing blame for that work. I have more vested interest in resolving the issue because if I do not, the colleague with which I work every day must. Because I rely on my teammates (smaller teams must, of necessity, rely on one another more than larger groups) I am much more likely to feel obligated to resolve any issues associated with my work that might trip up my colleague.

I have worked on several different software development teams and the one that was most effective in terms of delivering a product that customers used and appreciated was a small 2 person team that eventually grew to three people. The odd thing was that we delivered a working product much more quickly than the larger groups with which I worked even though the projects were similar in terms of size. The smaller team was able to make changes and enhancements much more quickly as well.

Six Sigma projects tend to be similar–if you have to spend significant time working out internal team process issues (as you are more likely to face with larger groups), you are less likely to make tangible progress.

Obviously, you have to have a large enough group to handle the task at hand. A high ranking (or at least very effective) champion that truly supports your process improvement goal is a necessity to remove barriers so that you do not need several additional team members to handle this work. And you need to cover all of the basic skills necessary to complete a project (e.g., someone that can access the necessary data, an analyst capable of valid statistical tests, etc.)

Summary: Keep your core project team small enough to operate efficiently and just large enough to have all the skills necessary.