Anecdotes are a dime a dozen. You need more solid information. There is some very good information for you in Software Estimation: Demystifying the Black Art. I already said a lot of this in Interesting insights from Software Estimation: Demystifying the Black Art, but I'll pull out the relevant points.

On page 229 you'll find a chart correlating team size with productivity. In that chart you'll find that the calendar months to complete a 57,000 product is about the same for a team of 5-7 people as it is for one of size 15-20. The cost is very different, there is some reason to believe that the quality and functionality is different (both in favour of the small team), but the schedule is the same. So be very, very careful about trying to throw more bodies at a project to make it go faster.

Now you can have a development organization with more than 5 -7people who uses the small team effect - you just have to have things divided into non-interacting projects with no more than a few people each. (But they have to really not have interactions - declaring it so by management fiat will not work.)

Starting on page 66 he presents the results of the Cocomo II effort multipliers. This is the result of a large study of many projects from many companies, which quantified the impact of various factors on development effort. The projects are generally larger ones, so these figures are more indicative than quantitative for small teams. The one that should interest you is that multisite development multiplies needed development effort by 1.56. So if they are looking at bringing in an offshore team, they should plan on reducing the productivity of the current team by quite a bit, and they have to be hiring enough people there to make up for that hit. Additionally they will go from having a small team to a large team, and to succeed in that they will need a lot more process which imposes its own overheads.

The result is that they should be prepared for a very real possibility that they will go from being able to use 10 developers to requiring more than 30 developers just to get the same overall throughput. Furthermore their ability to demand quick turnaround time on small projects is going to be severely compromised.

I know this sounds unbelievable. However it has been the experience of many other organizations in their position. They impose enough overhead to need to switch to large team dynamics, which means that they need to plan on over 20 to match the existing team, and then they have to plan on that team needing 56% more people to account for the overhead of multisite development. That takes you up to 31 people, and a lot of process, with no productivity gain!

Achieving productivity gains would require adding even more people.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.