Is there such a thing as too much staffing?

Many of us learn early in our lives all things, even good things, must be taken in moderation. Staffing for projects is one such good thing. I am sure we have all experienced projects that are run with too little resources. We know the normal symptoms of a project that is resource starved -- delays, quality and morale issues and perhaps failure.

However what would happen with a project that has too many resources? Would Brooks's law, which says that adding manpower to a software project that is behind schedule will delay it further, apply? Lets further complicate the issue by asking what would happen if the project begins with too many people to begin with, i.e. people are not being added late.

There are two common explanations for Brooks's law (http://wen.wikipedia.org/wiki/Brooks%27s_law) :

1. New staff take time and resources to ramp-up and are therefore not immediately productive and distract the experienced resources.

2. Communication overhead increases as we add more people. The number of different communication channels go up a square of the number of people.

However when the project is new problem #1 (ramp up time) is not a large contributor. However problem #2 -- communication overhead is a killer.

There is a 3rd problem that arises in the most extreme cases over-staffing; when the number of resources available exceeds the amount of work that can be performed at that time. When this happens in a manufacturing process we have idle machines. Machines are not aware of being idle and do not react to their idleness. People tend to be very aware of being idle. Idle machines might be ignored or eventually redeployed, Idle people usually become unemployed. So people start manufacturing work to stop being idle.

Work manufacturing can happen in two broad categories: scope creep and process creep. Scope creep usually refers to uncontrolled changes to a project's scope, but I am using it to mean changes that are not necessary to deliver the business case for this project.

Process creep is like scope creep except the changes are not made in deliverables of the project but the steps used to create the deliverables and manage the project. Of the two process creep is the more insidious because it is much harder to detect and control.