Strategic CIO // IT Strategy
Commentary
5/2/2013
10:28 AM
Connect Directly
RSS
E-Mail
50%
50%

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.

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 abhay@pobox.com.

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 tmedora@gmail.com.

Comment  | 
Print  | 
More Insights
Transformative CIOs Organize for Success
Transformative CIOs Organize for Success
Trying to meet today’s business technology needs with yesterday’s IT organizational structure is like driving a Model T at the Indy 500. Time for a reset.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - July10, 2014
When selecting servers to support analytics, consider data center capacity, storage, and computational intensity.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join InformationWeek’s Lorna Garey and Mike Healey, president of Yeoman Technology Group, an engineering and research firm focused on maximizing technology investments, to discuss the right way to go digital.
Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.