IT Project Teams: Big vs. Small


By John Parkinson

I have always liked big challenges. I once ran a project that had a budget (in today's dollars) of over $1B and in another career cycle, was responsible for the working practices of over 15,000 software engineers. I've worked with technologies that push the limits of physics.

But I have never liked big teams.

Team dynamics and project manager effectiveness interact in complex ways to get things done efficiently. Make the team too big and the dynamics tend to overwhelm the managers abilities, no matter how good they are. Process can compensate to some extent, but process tends to lead to bureaucracy and bureaucracy saps productivity and energy.

Diminishing returns set in sooner or later (usually sooner) and a death march commences.

On the other hand, too small a team can't contain all of the skills needed to do many real-world projects. Access to subject matter experts can compensate here, but the knowledge coordination challenges can be significant, and experts aren't always available just when you need them--and even then, they don't always understand the nuances of a problem that they are only peripherally involved in.

Schedules suffer as the team either waits for help or tries to invent a sub-optimal solution. Confusion reigns. Despair sets in.

It's hard to get the right balance between these two extremes. One rule of thumb I rediscovered recently (via a conversation with some folks from Amazon) is the "two-pizza rule." If it takes more than two pizzas to feed the team, it's too large.

Two large pizzas is between 24 and 32 pieces (at least it is where I buy pizza, although the pieces aren't all the same size) and assuming three to five pieces per person gives you teams of around six to eight people. That's enough to get work done but not too much to manage effectively. I might stretch this to 10 for some projects, or drop to four (two medium pizzas) for others, but these numbers correspond nicely to my experience of what works.

Really big projects are still going to need a lot of teams, so coordination between teams will be critical. The landing page at Amazon invokes around 300 separate services to build it and each service is supported by a team that must follow pretty strict rules if it's work is to integrate seamlessly with everyone else. That's why architecture is so critical.

Now if I could just find some really good architects...

John Parkinson is CIO of TransUnion. To read his columns for CIO Insight, click here.


2 Comments for "IT Project Teams: Big vs. Small"

  • Chris Weiss January 30, 2010 6:13 pm

    What a silly article.... Management is *always* the problem with poorly managed teams - big or small. I have seen plenty of teams of 10 or less drive a project into the ground that should have been successful. Fred Brooks discussed at length the issues around team size and complexity in 1975-> The Mythical Man Month. Every person you add to a team adds communication overhead, which means you need to chunk groups into individual teams so that this communication need is reduced and managed between teams with fewer people. Have you actually read this seminal book? It was updated in 2000. The book "Balancing Agility and Discipline: A Guide for the Perplexed," takes Brooks' discussion in a different direction so that processes can be tailored based on team make-up, project risk, and desired outcomes. Your article really expresses your own limitations and should not be taken as anything other than a whiny blog post.

  • Robert Rowntree December 15, 2009 12:23 pm

    The problem stems from managers (and column writers) that haven't got a lot of well, discipline. Discipline leads to acquiring the best knowledge available from well-regarded institutions that are known for producing good research. Yes, you can use the, "well this is my experience" argument. But a lot of people are doing things by trial and error -- like the columnist, in this case. Sad, but there is lots of research as well as real-world analogies out there that answer this question quite well. Think NHL. How many men on the ice? Take 5 seconds, 4, 3, 2, 1 -- times up. It's 5, 6 if you consider the goalie. the goalie would be a "weak" link into the 5 mobile players. NBA, what's the #? It's 5. NFL, well you say 12. But that would be a super-team size. Really its broken up into units -- back field and front lines. Ever heard of 5-4 defense? The 5 up front communicate loosely with the 4 supporting them. Two units essentially, not a unit of 9. So all this has been developed and tuned over time and gravitated to, you guessed it, 5. And Hackman in "Leading Teams" goes beyond just analogies although the sports analogies did come up with the right # mostly over a long time and lots of trial and error.

Leave a Comment