We did a process like this at a job once; it came back with an "estimate" of 240 developer-weeks, so the next question from management was "so we can have the feature in six months if we put ten people on it?"
I haven't read it but from what is commonly quoted it is about "Adding manpower to a late software project makes it later."
So the assumption of bringing n people to work on a projects increasing the productivity n-fold doesn't seem totally absurd when they are working on the project from the beginning. It might not be exactly n but (n-m) due to increased management, communication etc. So we might discuss how big is m? Still there should be some increase in productivity because that's essentially how huge projects work.
It's worth a read, if just to consider that many of the observations made in the industry during the 70's hold true today. Wikipedia has a summary of the book[1].
You can push it to the extreme and have two persons on each and every coding task. That's pair programming [1], which is said to be less productive, although it is argued you trade productivity for quality and other benefits.
It also does not like to be split cleanly into as many parts as there are people working on it; development work is not an embarrassingly parallel problem.