If you have never read Fred Brooks' The Mythical Man-Month, I would recommend doing so. First published in 1975, it contains some timeless wisdom distilled from Brooks' experience managing the design of the IBM System 360's operating system during the mid '60s. Brooks labeled one of his observations as "Brooks' Law," which states: "Adding manpower to a late software project makes it later." He explains that "adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and the added intercommunication."
A thoughtful reader may wish to probe more deeply into this issue, because he also says that adding manpower "may or may not help." Brooks prefaces his "Law" by saying, "Oversimplifying outrageously, we state Brooks' Law...." This suggests that adding manpower to a project that's late will work in special cases.
Brooks' central argument is that the total output of the development team will decrease over a period of time because the existing team members must repartition their work and train new team members. If this output loss exceeds the extra work done by the new members, then their addition produces no net benefit.
To save you time, I will recap the example that Brooks uses. A project with 15 man-months of work is incorrectly estimated to have only 12 man-months. A team of three people is assigned to work for four months. After two months, it's behind schedule, so two more people are added. Assume that one of the existing people spends a month training the two new people and they become productive during the last month of the program.
With this data, Brooks concludes that the project will be just as late as if the extra manpower hadn't been added. You have three man-months of unexpected work and gain only one man-month of net increased output by the end of month four. What management actions might enable successfully adding manpower in such a case?
First, add extra resources as early as possible. The later you add them, the lower the payoff. Also, add more resources than you think that you will need. If you don't, you might have to add resources again, leading to what Brooks humorously calls a "regenerative schedule disaster."
Train the new resources as quickly as possible, even when this requires taking resources away from the project. The real cost of training isn't the time invested by the instructor, but the fact that the students aren't yet productive.
Furthermore, if possible, do the training off the project's critical path. Think of training backup resources as an insurance policy. Operate with some team members supporting more than one project. When you work on a project part time, you can increase the number of hours devoted to this project. In contrast, there's no surge capacity when you're assigned full time to a project.
Finally, partition the design into small enough chunks of work that repartitioning won't be necessary. Consider partitioning the design into smaller chunks than are technically necessary because this will create the flexibility to shift workloads between resources.
My central point is that it's how you manage that determines whether or not adding resources will help you meet the schedule. There's no fundamental law that always makes it a bad idea to add resources to a late project.
Reprints
