Size Matters: Smaller Project Teams Are Better

Big teams can cost your organization time and money – and possibly the project itself. Here's how to pare down.

Abhay Padgaonkar, Contributor

May 2, 2013

6 Min Read

10 Must-Have WordPress Plugins For Businesses

10 Must-Have WordPress Plugins For Businesses

10 Must-Have WordPress Plugins For Businesses(click image for larger view and for slideshow)

It's not complicated. Bigger is better -- if you are a cellphone company. But if you are a project team, the opposite should be true.

Why? Because the larger the development team, the more the number of interactions. These interactions don't just grow linearly; they explode exponentially. For a project team of 20, the number of possible interactions of groups of two or more can be more than 1 million!

Anyone who has worked on a large project team knows too well how chaotic, unmanageable and frustrating the process can be. Add to that team members copying their boss' boss on worthless emails to do a CYA or to show how well they are defending the turf, and the process can quickly get out of control. The project gets bogged down even more when you add different agendas and people across time, space and organizational boundaries to the equation. J. Richard Hackman, an expert in team dynamics, has advocated single digits in team numbers, with preferred group size being six.

[ Want more on project management? Read Project Management Offices: A Waste Of Money? ]

If it is so painfully obvious that large project teams can scuttle a project, why do so many project teams become bloated? That is because keeping the project team at an optimal size is hard. As Steve Jobs once said, "That's been one of my mantras: focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple."

Here are seven organization- and human-made traps that conspire to inflate the size of the project team, thereby rendering it less capable:

1. Lack Of Clarity

Organizations are good at launching a project, but not at clearly thinking through what the project is trying to achieve from a business perspective and why. This fuzziness in business requirements creates confusion, which in turn leads to over-design, accompanied with higher estimates for money, resources and time to account for the additional risk.

2. Failure To Communicate

Oftentimes, the business people and the technical people are on two different frequencies. The technical people don't understand the business language and marketplace challenges, and the business people don't grasp the technical jargon and constraints. This failure to communicate often results in project requirements that are overstated.

3. Political Correctness

When a powerful stakeholder announces a grand vision for the project, technologists are loath to question its wisdom. They are compelled to create an inclusive team on which every function or constituency is represented. Rather than arguing, they adopt the strategy of appeasement and compensate for it by inflating the estimates.

4. Too Big To Fail

In places that reward empire-building, the larger the project team, the higher the stature. The bigger the budget, the harder it is to bring down the project, and busy work expands to fill the resources available for its completion.

5. Trivial Pursuit

Many projects fall victim to Parkinson's Law of Triviality whereby disproportionate weight is given to trivial issues. Without a strong referee, it becomes very difficult to separate the tangential from the critical.

6. Peter Principle

Technology is evolving so rapidly, even technical people can barely keep up with it. The technologists either overcompensate for their blind spots, or if they are spread too thin -- especially the talented ones -- they err on the side of caution when it comes to estimating.

7. Easy Come, Easy Go

With increased offshoring of software projects, the "per resource" cost looks relatively affordable. This cheapness lulls the project leaders into throwing more resources at the project than is necessary.

What can project leaders do to avoid falling into these traps? Here are four quick do's and don'ts.

1. The Decider

Ensure there is a single project owner who is ultimately accountable for the delivery of the project. Ideally, this person should have substantial knowledge of the business requirements along with sufficient technical understanding to take ownership of the estimates. But the ability to understand, challenge and communicate business requirements is paramount. The project owner must aggressively work to control the business and technical scope while showing willingness to challenge team members in order to prevent poor decisions leading to unneeded complexity.

2. Don't Assume Leaders

It's easy for technical leaders to stagnate and rise to their level of incompetence (the Peter Principle in action again). Their superstar status based on past accomplishments can place them into roles about which they might know little. Organizations with integrated talent management processes for leadership and technical competencies are more likely to be able to assess this objectively, rather than simply assume it based on faith. The opinion of a trusted outsider can add perspective as well.

3. Show Me

It's easy to find people who will sell snake oil and claim that they can cheaply deliver quality results. Those who can back up such claims are rare, but they can provide a reality check for inflated internal estimates. A meaningful discussion with such exemplars about project scope, technical choices and relevant experiences can help calibrate resource-consumption estimates.

4. Choose Tech Wisely

Good technology cannot fix poor processes or lack of expertise, but poor technical choices related to platforms, architecture and tools can certainly cripple a project. The likelihood of errors of commission and omission related to platforms, architecture and tools can be reduced through due diligence: objectively laying out various options, vetting the pros and cons of each, and making informed decisions relevant to the project based on common sense.

But common sense is not all that common. Mark Twain once said: "I didn't have time to write a short letter, so I wrote a long one instead." Are your projects falling prey to similar bass-ackward thinking?

Abhay Padgaonkar is an award-winning management consultant, author, and speaker, is the president of Innovative Solutions Consulting. He advises clients of all sizes on challenges related to strategy, leadership, employee/customer loyalty, project management, and performance improvement. He can be reached at [email protected]. Tim Medora is the president of The Medora Group and is a leading IT strategist and implementer with successful projects in a dozen vertical industries. His portfolio includes Fortune 500 companies, startup ventures, and non-profit organizations. He can be reached at [email protected].

About the Author(s)

Abhay Padgaonkar


Abhay Padgaonkar is an award-winning management consultant, author, and speaker. He advises clients on strategy, leadership, project management and performance improvement. Abhay has authored many management articles in Projects@Work, Performance Improvement, Marketing Profs, Leadership Excellence,, and many other publications. He has been quoted in publications, including the Wall Street Journal online, HR Magazine,, and The Business Journal and in books such as "The Matrix Organization Reloaded" and "Straight Talk: Oral Communication for Career Success."

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights