Copyright © 2009 Corvus International Inc. All Rights Reserved
The relationship of effort to time expended in manufacturing is generally a linear one*. If we double our capacity, we reduce the time to create a certain amount of product by 50%. If we double the time taken, we'll build twice as much product.
This is not true for software development. A 10,000 staff hour project cannot be completed in one hour by putting 10,000 people on the job. In fact, if a 10,000 staff hour project takes a nominal 11.5 months (which is about what it would take), with an average of five staff, doubling the staff to an average of 10 will NOT reduce the schedule to 5.75 months. In fact (depending on a number of other factors), to reduce the schedule to 5.75 would require around 160 people (!). Doubling the average staff from five to 10 would only chop off 1.5 months.
Most project managers know this in their gut. We have learned through years of painful lessons that adding people doesn't much help a project come in earlier. In fact it can be counter-productive. As Fred Brooks said: "Adding manpower to a late project makes it later." .
There are two reasons for this: the "physics" of projects, and the types of work we do on projects
Physics of Projects
The relationship of effort to time on a project is not linear, it is approximately a fourth-order reciprocal exponent. That is:
EFFORT ~ TIME-4 
Plotting this relationship gives this graph
This means that, as project schedules are compressed, the effort doesn't just go up, it goes up enormously. But why?
This behavior is related to the type of work we do on projects:
The Type of Work We Do on Projects
I've already alluded to the fact that a software project is primarily a learning activity, rather than a "production" activity, and that the production of a system is a by-product of the learning. The functioning executable system is simply where we put what we've learned. It just so happens that in this medium, what we've learned executes.
There are three kinds of work we do on projects:
Real Work--this is the activity of transcribing what we know into the executable form called "software"
Necessary Friction--this is the discovery of what we don't know. Of course, for those things we don't already know we have to do this kind of work before we can do the real work
Optional Chaos--this is simply the "Brownian Motion"  of projects. It is noise, waste, do-overs, and of no value
The total effort on a project is the sum of these three different kinds of work, but their ratios are not constant. They vary with respect to the time taken on the project.
At any point on the Time-Effort curve, the Effort (Y-Axis) is the Real Work plus the Necessary Friction plus the Optional Chaos.
So what happens if we relax or compress the schedule?
When we relax the schedule on a project, the Real Work stays about the same, the Necessary Friction reduces somewhat and the Optional Chaos almost disappears.
When we compress the schedule, the Real Work stays about the same, the Necessary Friction increases somewhat, and the Optional Chaos explodes.
This means that when we compress a project schedule, much of the work goes into waste. Usually management does not realize or understand this.
By adding 40 more people to your project you may be getting only 39 people's worth of noise and one person's worth of work. Adding another 40 people might give you 39.75 people's worth of noise and only 0.25 person's worth of value.
This is one of the dirty little secrets of software development. The executives who authorize the resources for software projects think that every single hour of every single day of every single person is going into the project to produce "product". It is not.
These curves are the "theoretical" ones. Adding more and more people makes the curve more and more vertical. But I think in practice the curve curls over if the schedule is compressed too much so that adding additional effort just pushes the schedule back out--at much higher cost of course.
Fred Brooks thinks so too: "adding people to a project that is running late, will make it run later...".
* It is more complex than
this, being (amongst other things) a step function of manufacturing
capability, but we're keeping it simple here
 The Mythical Man Month. Brooks, Fred Jr. Addison-Wesley 1974 p.25
 Measures for Excellence, Putnam Larry, and Myers, Ware. Yourdon Press 1992
 After Scottish Botanist Robert Brown 1773-1858