Frederick Brooks famously said that adding staff to a late project only makes it later. The reasons are readily apparent. The project is already experiencing difficulties, most of which were not caused by understaffing. The usual culprit is an unreasonable schedule constraint; but starting work before the requirements were well defined, poor change control, or weak configuration management could also be the villains (or at least play a contributing role). None of these root causes is staff related and adding staff does not fix them: it merely adds more bodies to the confusion.
But, how do we determine the most appropriate staffing profile for a software project? Parametric estimation models suggest a way: these models have determined that there is a relationship between the functionality that a project delivers (called size in the software estimation vernacular) and staff. Fitting a regression line through hundreds or thousands of software projects determines an average and deviation from that average. The regression is a reflection of how software projects have performed. This is what has worked. This capability is built into estimation software like SLIM-Estimate. A wise approach is to take the average as a starting point, then adjust the modeling parameters that would increase or lower the staff. A word of caution here: if you find that your adjustments cause staff, effort, or duration to be more than 1 standard deviation above or below average, you are probably being either too optimistic or pessimistic. Don’t do it!