It is not necessarily a technical issue but many technical projects sometimes suffer from a project team that is too large. It usually happens when management has decided on a delivery date that cannot be met with the current amount of manpower and for some reason it is more logical to them to add more developers than to move the date. Realistically there are valid times when a date cannot move, but merely adding more developers usually gets to a point of diminished return rather quickly.

 A good friend of mine was fond of saying “You can't get nine women and make a baby in a month.” Take the situation where you have a team of 3 developers and the estimated time for development is 6 weeks. That does not fit the desired schedule so you double the development team to now be a total of 6. So that means we should get a deliverable in 3 weeks now, right? Probably not. Most likely it would be closer to 5 weeks, and if you are not careful it would be right back at 6 or more with a poorer quality deliverable.

Why does this math not work? Anyone who has been in the situation above can tell you that adding more resources usually means someone (usually the team lead) will end up spending more time managing the additional resources and coordinating between them than they will actually developing. So one of your original developer’s actual availability for development tasks will be reduced greatly. The other’s productivity will be hurt also since more coordination means more meetings, more need for documentation, etc.

Another factor of adding more people to the project team is that it usually happens well into the project. This is also known as the “Oh, crap!” factor. That means all the new developers have to be brought up to speed on the project which takes the existing team members away from development tasks.

You might think that adding senior people will make that transition smoother. Not so much. You will then experience “Did you think-itis”. This is a syndrome where the new senior developers will ask a question starting with “Did you think of…” about every architecture and design decision. I have been just as guilty of this myself. I have also been on the receiving end where you do not have time to explain the 30 hours worth of meetings that led up to the one design decision.

So what is the answer? If I knew that I would tell you at a rate of $500 an hour. I can say that in my experience the best way to avoid this situation is to consider the following:

• Rigorously review requirements, development tasks, and time estimates to make sure your project time line is as accurate as possible. It means more work upfront, but it can save your hide in the end.
• Get your development team set early on. This is hard to do with resources in a large IT shop, but getting your core team together early on and involved even before development helps them understand the project tasks and goals more.
• Document EVERYTHING. This helps out with many other issues, but thorough documentation helps get new team members up to speed quicker and allows them to operate with less hand holding.
• Make sure new additions fit with the team. Pure technical competence is not enough when working with a close knit team under the pressure of a short timeline. Personality, professionalism, attitude, self-reliance, and leadership capabilities all play a vital role. Make sure to involve your team in the interview process and take their council to heart.
• Do not add bodies for the sake of adding bodies. We know the math in the scenario above rarely works. I would rather work 16 hours days for a few weeks with a small, solid group of developers than spend 8 hour days will a large, rag-tag group for a month.
• When bring in a senior resource midway through a project, set their expectations up front. Everyone wants to prove themselves, but being very open and honest with a new senior level resource about their involvement can save you a lot of pain. There are times when you have to say “shut and code!”

There are many other factors to consider, but merely acknowledging that simply adding more resources is not going to always drastically reduce development time is a good first start.