Top Performing Projects Use Small Teams

<< QSM Consulting Receives Four... | Main | Part II: Small Teams Deliver Lower... >>

Last week, Carl Erickson of Atomic Spin referenced a study performed by Doug Putnam several years ago:

A study done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Since then, QSM has performed several studies investigating the relationship between team size and metrics like project scope, productivity, effort/cost, and reliability. The results have been surprisingly consistent regardless of application domain, technology, or year group.  I’ll be reviewing what we found in a series of posts.

Best in Class Software Projects Use Small Teams

In a study performed for our 2006 IT Almanac, Don Beckett examined the characteristics of Best and Worst in Class projects. The one thing that jumped out almost immediately was the influence of team size.  To identify top and bottom performers, he ran regression fits for effort and schedule vs. project size through a sample of nearly 600 medium and high confidence IT projects completed between 2001 and 2004. These projects were drawn from the QSM database of over 10,000 projects and included a broad range of languages, technologies, development environments, countries, industries, and project types.

Using the plus- and minus- one standard deviation lines for schedule and effort as boundaries, projects above the plus one σ line became our Worst in Class sample. These poor performers took significantly longer and used more effort than the majority of projects in our sample. How much worse were they? Worst in class performers took longer and used more effort than about 84% of the sample. Projects below the lower 1 sigma lines for effort and schedule  became our Best in Class projects.

The differences between the two groups were striking.  On average, Best in Class projects delivered 5 times faster and used 15 times less effort than Worst in Class projects.

What could be causing the disparity in schedule and effort/cost performance between best and worst in class projects? The characteristic that stood out from Don's analysis was team size. Best in Class projects used teams (over 4 times smaller, on average) than the worst performers.

This is the first in a series of posts that will look at the effect of team size on project performance, cost, schedule, and reliability from a variety of perspectives. The next post in the series will review a repeat of Doug’s team size study using a sample of 1060 IT projects completed between 2006 and 2011.

Read more QSM blog posts about team size.

Related Posts

Back to Main Blog

Comments

I would have suggested a team

I would have suggested a team size of 7+/-2 (Miller's Number) to include the team lead. There are assumptions that should be stated.

The amount of work (taskings) is known, defined, and do-able. The team members are sufficiently trained. The team members are educated. The team member personalities all get along or conflict resolution methods are clearly defined and enforced. The user requirements are known or gathered and agreed upon. There is a good Change Management system. There is a good Configuration Mangement system in place. There is a good defect tracking system. Design and Coding standards and guidelines are all agreed upon.

The small team (7+/-2) should be trained in Agile or PSP/TSP at the beginning.

There is another related

There is another related problem that plagues large systems and large projects and that is, while individuals may have a good grasp of their pieces of knowledge, perhaps nobody really understands the entire system.

I think this is a critical insight. Chopping complex work into smaller, more manageable "chunks" reduces the complexity of the individual chunks (and thus enhances measured productivity), but does nothing to reduce the complexity of the sum of all the chunks. If anything (as you so aptly noted) it makes it harder to grapple with the complexity of the system (as opposed to iteration or project).

Great comment - you've given me a lot to think about!

- Kate Armel

Why larger teams are often challenged

There are probably quite a few reasons why smaller teams function better. 

Number of Communication Channels

A commonly cited one is the geometric increase of possible communication channels with number of people.  With n members on a team the number of 1:1 communication channels is given by n(n-1)/2.  So for five people on a team the number of channels is 10, but for a median of 27 people on a team the number of channels is 351.  Larger teams attempt to manage this by implementing layers of management and communication hierarchies.  This does cut down the number of required channels, but it introduces communication queues and their associated delays.  It also introduces the probability that messages will get lost or garbled.

The Effect of Knowledge Partitioning

There is another reason why having more people on a project is often a detriment to effective development.  A functioning system is a highly interconnected collection of knowledge that has been collected, structured, and transposed into the executable knowledge medium we call code (with its associated and supporting data structures).  The system is a system because the knowledge it contains is connected.  When we chop up this knowledge into smaller pieces so that we can speed up the process by having multiple people collect it, structure it, and make it executable, the knowledge becomes disconnected.  Perhaps each piece of knowledge that each person works on does reasonably describe what it should do, but the whole does not.  And the more parts we chop it up into, the more likely it is that it will not easily go back together to make a consistent whole.

Standard Interfaces and Problems with Integration

We have come a long way in terms of implementing modularity through standard interfaces and design patterns, especially for application support functions.  This does help reduce disconnects in partitioning, though sometimes at a cost in flexibility and performance.  But a logical application system must still be a consistent body of the logical application knowledge both within the system and between the system and the outside world it is serving.  This partitioning problem is compounded by the fact that each small piece might be quite understandable and functional on its own and the problems only surface when we try to put them together.  This knowledge integration often occurs late in the development cycle when the project has few degrees of schedule freedom to respond to problems and inconsistencies.  This is one of the reasons Agile approaches recommend building and releasing something that works early and often is a good idea, since it tends to force this integration activity.

Understanding Large Systems

There is another related problem that plagues large systems and large projects and that is, while individuals may have a good grasp of their pieces of knowledge, perhaps nobody really understands the entire system.  The modern project focus on systems’ architecture (which is the over-arching structure of the system knowledge) is a worthy attempt to mitigate this problem.  But we are still limited by our individual and collective abilities to understand large and complex systems. 

To some extent a system is like a pizza: we can leave it in one big piece or we can cut it up into lots of smaller pieces, but it’s still a pizza and it doesn’t get smaller by cutting it up.        

Optimal team size

Given the wide range of staffing strategies, I've been really surprised at how consistent some of our team size findings have been. This has been true regardless of the study method, sample data, or management metrics used.

It's rare to see the data tell such a consistent story, but I'm happy that ISBSG's data is saying the same thing. I'll be writing about optimal team size in the 3rd post in this series (later this week). We've found that the optimal team size varies with project size but across the size spectrum, small teams nearly always perform better than large teams.

- Kate

team size

This is consistent with the ISBSG findings. A team size of about 4 people seems to be optimal in most cases.