Classic IT paradigms suggest that the larger and more complex the problem, the larger the required team (within reason). For small projects, a leader and a small team of technicians are best suited. For the largest initiatives, we break down the problem into streams of work, assign each to a team, and apply program management principles to govern the coordination of the multiple streams. There are natural boundaries of effective coordination and scale, limiting the maximum size of an enterprise program, but I have personally seen classical thinking applied to programs of 200 people or more, and software development projects that last 2 years or more. Most of the time, this doesn’t work out very well.
Dozens of studies suggest that, as IT projects grow in size, they encounter greater risk, and those lasting more than a year have a dangerously high likelihood of never being launched. This matches my experience. In the last decade or so, I have applied a couple rules of thumb to determine the size of a “manageable” IT initiative: if a project lasts longer than 6-9 months or requires coordination across 4 or more streams, break it up. Even shorter if the application is consumer-facing, which normally demands iterative learning and continuous improvement. There are exceptions, but this basic rule has served me well. Still, some IT leaders must not agree, since classic mega-programs still get sponsored.
I was reminded that different points of view exist on this topic a few weeks ago. One of our clients’ executives remarked that he had seen a stark difference in results from two similar projects recently. A small team had completed far greater scope in far less time than a much larger team. The cost difference was dramatic…..not 50% different….10 times different! The question is: why?
- Process plays a part. Many organizations have adopted Agile, or one of the numerous variants, trying to create self-managed teams that drive short-term results with greater clarity. We are trained on nuanced roles, the right vocabulary and new ceremonies. And it normally helps. At a minimum, a 2-week sprint normally doesn’t experience huge changes in scope, allowing the team to complete their short-term goals. But, we have seen lots of organizations get poor results from agile adoption. Simply applying a process is clearly not enough.
- Individual excellence plays a part. We would all love to work with only “A” players – but that is not always possible. As we form our teams, be understanding (and transparent) about the roles that people are to play, and ways in which they can grow as part of the team. One of the hidden value propositions of self-managed teams: in a respectful culture, team members will help each other grow, often more effectively than any performance review process.
- Clarity plays a part. My experience suggests that most IT projects don’t fail due to technology. They often fail due to clarity. It is surprising how often the goal is misunderstood, the team doesn’t feel truly empowered, the roles aren’t clear, or the team was not part of defining the approach in the first place. Another wonderful value from agile: self-managed teams who control their destiny will take greater ownership, hold each other more accountable, and deliver more. Pretty much every time. The small team above was a classic example.
- The interpersonal fabric of small teams is fundamentally richer than larger ones. Small groups connect better. They share experiences, both on the job and at the local pizza place. They listen to each other more, know each other’s name, understand each other’s perspective (even if they disagree), acknowledge strengths and weaknesses that might not be apparent, and communicate in respectful, less formal ways. Small teams form greater trust.
The lesson for IT leaders? We need to leverage the power of small teams. Empower and trust them to control their destiny. Listen to their views. Give the team members opportunities to grow their leadership skills. And reinforce the importance that each person plays in the fabric that is the engine of small teams. I have personally seen some amazing stuff come from it.
