This is the data.
estimated development workload: 3000 man/days
team size:technical lead, 4 database designers, 4 application designers, 9 developers, unknown number of testers.
available time: 5 months
The team was brought together from all sides a month ago. Team quality is "usual" (half is quite experienced - half interns). Four members of team have substantial experience in the field (3 application designers and technical lead). Other members of team have no experience in the field.
The team's opinion is that optimistic ETA for delivery is 12 months (with p~0.7), unless scope is cut. TPTB declare that this is not an option and are willing to pursue various arcane options (basically throwing money at problem).
The team estimates that max. 30% (you are allowed to assume 50%) of projected scope is subject to potential replacement with "off the shelf" components where the most optimistic scenario is assumed to cut the time spent on these modules by 50% (due to evaluation, modification and integration).
What I'd like to ask is - what are your experiences in such situations? I strongly suspect that adding more people will only amplify the problem in our current situation. So I insist that scope needs to be cut or deadline needs to be renegotiated. As mentioned - both appear to be non-negotiable.
Is my reasoning flawed? What other options are there?
2) Your team already sounds quite big for a supposed 5 month project. Feels like people will be stepping on each others toes, and someone will be tearing ther hair out trying to manage everyone modifying the same codebase whilst it is so immature.
3) The Iron Triangle - this is the relationshp between scope, resources/cost, and deadline dates. If you can't build what is in scope, with the resources you have by the date specified then somethings got to give. Hint: increasing resources is the least effective way of doing this, see 1) above.
4) Have you tried approaching this in an Agile manner? Prioritise all the functionaltiy thats in scope, tackle the most important first. Continually refine the priority of functionality as you develop the system. If that deadline is immovable, and you're not going to get all the functionality in, at least you've delivered the most important parts of the system. What you might find, if everyone gets Agile, is that they realise you won't hit the deadline early on and they start buying into this approach, by prioritising they are in effect reducing scope without realising it.
5) in conjunction with 4) monitor the productivity and efficiency of your team using burndown charts. Note that this is different from speed of development. The concept of technical debt is integral in all of this; productivity & efficiency take into account technical debt and implies you are trying to manage it, speed usually increases technical debt.
6) Finally, tell people "things take as long as they take". Just because someone says they want it by yesterday doesn't mean that it can be built by then.If they want to bake some bread it will take them approximately an hour or so, if someone told them to do it in 20 minutes they wouldn't be able to knead the dough and bake it in that time - and get something edible at the end. Essentially that is what you are being asked to do.
My two-penneth
Good luck!