Can a Team be too Big?
By Russ Finney
System development projects come in all shapes and sizes. At many smaller companies, a project "team" may only consist one to three people working on a specific business application. Conversely, at a huge corporation, a multi-year project may involve literally hundreds of people. So does an optimal size really exist for the number of people who should be on a development team for maximum effectiveness? Fred Brooks, in his book The Mythical Man-Month, puts the recommended number at ten.
In this context, he describes the various roles these ten people should assume. The team leader, in addition to the usual administrative duties, is responsible the for the overall business and technical "architecture" of the system, and the methods, approach, and techniques which will be ultimately employed throughout the development effort. He or she should have several sub-team leaders who take the responsibility for either a functional business area or a technical specialty (such as on-line lead, batch lead, or data base administrator). The rest of team members fulfill support roles as needed for programming, data modeling, process modeling, testing etc. The key to this approach is the team leader is a primarily system architect first, and his or her administrative duties take second place to this overriding responsibility.
Mr. Brooks also gives an excellent analogy of the similarity between a project team leader and a medical surgeon. In an operating room, the surgeon decides which techniques will be used, the surgical methods which will be followed, and the course of action if a crisis should occur. The surgeon is thus accountable for the outcome of the operation, and the remaining surgical team members are present to assist and to make recommendations. This is very similar to the situation with which the project team leader is faced. But how can this optimal organization be utilized on very large projects where over twenty, or over fifty, or even over one hundred people may be involved?
The answer is: don't change the approach. The development effort must be sub-divided in such a way that each piece can be assigned an optimal mix of team members along with an accountable team leader, who takes responsibility for the role of system architect for that sub-system. The trick is to build an effective oversight organization to coordinate the activities of these sub-project teams. This means that a master system architect must be appointed to oversee the activities of all the team leaders. In many cases, this individual may needs a separate staff to help support the overall administrative, coordination, and decision responsibilities he or she will be facing. This is where the project bureaucracy begins to take shape, and the key is to make sure that its primary focus is on communication and integration, rather than administrivia and red-tape.
Listed below are several success factors to consider when assembling a very large project team:
- The overall project should be lead be a master system architect who is vested with the final decision authority on functional, technical, methodological, scope, and approach issues. He or she must empower the team leaders to work independently, as well as insuring that the sub-team's efforts are centrally coordinated and integrated.
- Each sub-project (made up of a maximum of ten people), should be lead by an experienced, proven system builder who recognizes the importance of cross-team communication. This person must be vested with the same level of accountability as if the sub-project was a "stand-alone" effort.
- Clear standards should be set by the master architect, after receiving the advise and council of the team leaders. These standards should foster both the seamless integration of the sub-systems as well the creation of a consistent product from the diverse project teams.
- All workplans, budgets, and schedules should be compared and coordinated on a regular basis. Timing problems and schedule inconsistencies must be quickly identified, and the team must remain open to rapid contingency planning.
Copyright © 1999, Russ Finney, All Rights Reserved