- Date published:
- Author:Brian Wood
Here’s a concept that resonates especially well with me: the advantage of small teams.
Small drives prioritization, necessary tradeoffs, and clarity of objectives. It’s why I work for a small company and why I lead a small team.
This “smallness” is often easier said than done for development projects, however, especially within large organizations where quantity (people, budget) has a quality all of its own.
Summary article by Caron Carlson in FierceCIO, original by Abhay Padgaonkar and Tim Medora in InformationWeek.
Emphasis in red added by me.
Brian Wood, VP Marketing
The virtue of a small team
Alas, the big software project. One way to avert disaster may be to take the “big” out of the equation. By reducing the size of a development team, you can cut back dramatically on the management challenges, advise consultants Abhay Padgaonkar and Tim Medora in a post at InformationWeek.
The writers’ proposition is straightforward: The smaller the team, the fewer the number of interactions and the greater the manageability.
“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!” Padgaonkar and Medora warn. “Add to that team members copying their boss’s 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.”
Trying to manage this is often a brutal exercise in frustration or outright failure. Why not try a small team instead? The ideal team size is six, according team dynamics expert Richard Hackman. Just make sure you have a single project owner, and preferably one who understands both the business requirements and the technology–and has excellent communication skills.
Keeping a team small is hard, though, and there are seven traps you should look out for, warn Padgaonkar and Medora.
- Lack of clarity
- Lack of communication
- Political correctness
- Rewards given for empire-building
- Preoccupation with trivial pursuits
- The Peter Principle
- Easy come, easy go attitude
Fierce’s Take: Yikes. If we sprinkle in turf wars, colossal egos and nepotism, these traps sum up the modus operandi at a non-profit I once worked at. (And there are only a few people I’d wish that particular hell on.) Weeding the extraneous personalities out of some of the projects there could have saved a lot of time and money. Influence doesn’t have to correlate to the size of a team or its budget. It might be worthwhile to attempt a small team for your next project, but I wouldn’t try it without first lining up a trustworthy, high-level counterpart on the business side to help champion the idea and the project.
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.
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.
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?