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.