Small is Good: Small projects with a single person who both knows the details of the problem and implementation is the ideal situation. That's basically what happens in a one man project. If only all projects could be as efficient! Any time it is possible to attack a problem with a small team of very smart people that's always the best way to go.
Unfortunately, some problems are just too massive to work that way. It is usually most efficient to either hire someone a little more experienced who can keep it in one-man-land, or add a second or third senior engineer. What if that's not enough? Then it's often best to have a clear teachnical lead who can specialize in decision-making. This kind of thing usually holds up to about 7 or 8 people. Beyond that there's a HUGE dropoff in productivity. Growing a project team beyond that size is just asking for trouble and should only be done when there's no other choice.
Larger teams often bring serious practical and political hazards. One is that management often thinks that it is OK to insert people who have no idea what is going on. Often this person is called a "project manager". Worse, they often insert such people into a diffuse decision-making process.
If non-technical people are involved in a projct it is best that they be "doing" and not "supervising". There are things that non-technical people can do under the direction of technical leadership: user docs, artwork, testing, and some kinds of documentation. That can help take the load off the technical staff and speed things up. Putting them in charge has in every case I have seen been a wet blanket on the project. Worse, as soon as non-technical people get in charge of things, they usually bring in more non-technical managers to "help". In one case I know of, two technical managers were replaced by 90 non-technical managers to manage a smaller number of engineers and development has all but ground to a halt.
Often the nature of projects themselves can help tame this problem. Sometimes they are natually divisible into small projects doable by one person or a small group. Norton Utilities was a good example of this. As I recall there were 17 of us working on the thing, but it worked because it was really 17 one-man projects only loosely coupled together. Sometimes certain aspects of the project can be automated or simplified through design choices. For example, a small team developing a core engine that can be driven by scripts can keep the core development team small and create lots of small projects to write scripts (usually this can be done by less expensive people too). Sometimes none of these things are possible and you just have to bite the bullet, but that doesn't mean that mindless bloating is OK. Using creative ways of keeping things small is the best way to go even if you are on a huge project. A 50 person project is still better than a 100 person project.
While I have been talking in general terms about typical kinds of projects, it is worth noting that no project and no team is "typical". There are always unique obstacles and unique opportunities to be identified in any environment, and one of the most common errors I see out there is people applying recipes (even good ones) rather than looking at what is in front of them. Imagine if mountain climbers knew a lot about their tools and about a "typical mountain" but never bothered to actually study the specific mountain they were climbing and didn't bother understanding ythe group dynamics of their climbing team members. Such people would quickly remove themselves from the gene pool just as Darwin described. Unfortunately when such errors strike software project teams the survivors just move on to the next company. Darwin will have to wait for another day for them. [From a discussion on TechRepublic]
4:20:08 PM 
|
