The most tempting fix in project management
A project is slipping. The sponsor is anxious, the deadline is public, and someone in the steering meeting says what everyone is thinking: "Let's put more people on it." It sounds responsible. It feels like action. And on many projects it is exactly the wrong move.
In 1975, Fred Brooks, who had managed IBM's huge OS/360 software project, summed up the lesson in one line that became known as Brooks's law: "Adding manpower to a late software project makes it later." To explain why, he used an image that has outlived the rest of the book: the bearing of a child takes nine months, no matter how many women are assigned [1][2].
The core idea: some work can be split among more people, and some cannot. When the work is sequential, complex or already late, extra people add training, coordination and rework faster than they add output.
The mechanics
Why more people can make a project later
Brooks gave three reasons, and later research added a fourth. Together they explain why a person-month is not a unit you can freely trade for calendar time [1][2].
1. Ramp-up takes time from your best people
New people need to learn the product, the codebase, the business rules and the team's ways of working. The people who teach them are usually the most experienced members of the team, the same people the late project depends on. For weeks, total output can go down before it goes up.
2. Communication grows faster than the team
Every pair of people is a possible communication channel. With n people there are n(n−1)/2 channels. Going from 5 to 10 people doubles the team but more than quadruples the channels, from 10 to 45 [3]. More meetings, more hand-offs and more chances to misunderstand.
3. Some work cannot be divided
Painting a fence or cleaning hotel rooms scales with people. Designing an architecture, making a key decision or finding a subtle defect does not. When tasks depend on each other in sequence, the critical path sets the pace, not the headcount.
4. Effort per person drops in bigger groups
As early as 1913, the French engineer Max Ringelmann found that people pulling a rope in a group each pulled less hard than when they pulled alone. Later experiments with fake team-mates showed this was not only poor coordination but a loss of motivation, now called social loafing [4].
| Team size | Communication channels n(n−1)/2 | Change |
|---|---|---|
| 3 people | 3 | — |
| 5 people | 10 | +7 |
| 7 people | 21 | +11 |
| 10 people | 45 | +24 |
| 15 people | 105 | +60 |
| 20 people | 190 | +85 |
Try it yourself with the free communication channels calculator.
The data
What the evidence says
Brooks wrote from experience. Since then, researchers have tested the idea against thousands of real projects. The pattern is consistent: bigger teams buy a little time at a high price.
| Study | What was compared | Key finding |
|---|---|---|
| Putnam, QSM (1997) | 491 completed software projects | For medium-sized systems, teams of about 3–7 people were the most efficient [5]. |
| Putnam, QSM (2005) | 564 business systems projects: teams under 5 vs teams over 20 | For the same size of system, large teams finished in 8.92 months and small teams in 9.12 months: about one week faster for four or more times the people [6]. |
| Beckett, QSM (2006) | Nearly 600 IT projects: best vs worst in class | Best-in-class projects used teams over 4 times smaller, delivered about 5 times faster and used about 15 times less effort [5][6]. |
| Armel, QSM (2012) | About 1,060 IT projects: 4 or fewer people vs 5 or more | Larger teams gained only a small schedule advantage but cost 3–4 times more and produced 2–3 times as many defects [5]. |
| Putnam, QSM (about 2018) | 390 projects of the same size: under 4 people vs 9 or more | Larger teams cut the schedule by about 30%, but cost rose about 350% and defects about 500% [5]. |
| Hackman and Vidmar (Harvard) | Team members rating whether their team was too small or too large | The ratings balanced at about 4.6 people [7]. Hackman's later rule of thumb for teams: "no double digits" [8]. |
| Scrum Guide (2020) | Guidance for agile teams | Scrum teams are "typically 10 or fewer people", because smaller teams communicate better and are more productive [9]. |
Most of this data comes from software and IT, where Brooks's law was first described. The same forces, ramp-up, coordination and sequential work, apply wherever work is knowledge-heavy: business analysis, design, policy, research and change management. Large engineering and construction projects show a related pattern: delays and rework often surface late, when adding resources is most expensive [10].
It is not an iron law
Brooks himself introduced the law as an "outrageous" oversimplification [1][2]. Two well-known follow-ups refined it:
- Timing matters. A 1999 simulation study by Hsia, Hsu and Kung found that adding people always raises cost, but does not always delay the project. If people are added early enough, and the work is not tightly sequential, the deadline can still be met [2].
- Late projects are often underestimated projects. In "Brooks' Law Repealed" (1999), Steve McConnell argued that the law mainly applies in the final stages. Many projects that look "late" were simply under-planned, and adding staff early, with time to become productive, can help [2].
So the better question is not "Does adding people ever work?" but "Will these people, added now, to this kind of work, produce more than they consume?"
| Adding people is more likely to help when… | Adding people is more likely to backfire when… |
|---|---|
| It happens early, with time to ramp up | It happens in the last weeks before a deadline |
| The work splits into independent packages | Tasks are sequential or tightly coupled |
| Newcomers already know the product, tools or domain | Only a few experts understand the system |
| The added work is off the critical path (testing, data entry, documentation) | The bottleneck is a decision, an approval or a specialist |
| A new, separate team with a clear interface takes a whole stream | New people join the same team and the same backlog |
| Onboarding is planned and led by someone not on the critical path | Your busiest experts must stop to train newcomers |
An illustration
A worked example
The numbers below are illustrative, not from a real project. A team of six is building a customer portal. With eight weeks to go, it is four weeks behind. The sponsor offers four more developers.
What the sponsor expects
Six people become ten, so the team moves about 67% faster. Four weeks of delay disappear.
What often happens
- Weeks 1–3: two senior developers spend about half their time onboarding the four newcomers.
- Communication channels rise from 15 to 45; stand-ups and code reviews take longer.
- Newcomers' first changes cause rework because they do not yet know the business rules.
- The critical path, integration with the billing system, still depends on one specialist.
The likely result
Higher cost every week, a small or zero gain in the schedule, and more defects to fix before go-live.
A better option
Cut two low-value features, move testing and data migration to a separate small team, protect the billing specialist from all other work, and agree a staged release with the sponsor.
What to do instead
Ten better ways to recover a late project
- Re-estimate before you react. Find out how late the project really is, using actual performance and a forecast (for example earned value or a Monte Carlo schedule simulation), not hope.
- Find the true bottleneck. Look at the critical path and where work is waiting. If the constraint is one specialist, one approval or one vendor, more general staff will not help.
- Reduce scope. Prioritize with the sponsor (for example MoSCoW) and deliver the must-haves first. Removing work is the fastest way to finish sooner.
- Release in stages. A minimum viable release on the original date, followed by the rest, often meets the real business need.
- Fast-track with care. Overlap tasks that were planned in sequence, knowing it adds risk and possible rework [11].
- Crash selectively. If you add resources, add them to specific critical-path tasks where each day saved costs least, and check whether the critical path changes [11].
- Add people early and as separate teams. If more people are truly needed, add them as early as possible, give them a whole, independent piece of work and a clear interface, and plan their onboarding [2][12].
- Protect your experts' focus. Remove meetings, reports and side tasks from the people on the critical path. Their hours are your scarcest resource.
- Limit work in progress. Finishing fewer things at once shortens cycle time and exposes blockers. See how this works in the Kanban flow simulator.
- Reset the plan openly. Present the options, the trade-offs and the data to the sponsor, and agree a new baseline through change control rather than a promise you cannot keep.
Remember the PMBOK® view: schedule compression always has a price. Crashing adds cost, and fast-tracking adds risk [11]. The project manager's job is to make that price visible before the decision is made.
Questions to ask before adding people
- What is actually causing the delay, and will more people fix that cause?
- Is the remaining work divisible into independent pieces?
- How long will newcomers take to become productive, and who will train them?
- How many weeks are left, and is that longer than the ramp-up time?
- How will the team structure change: one bigger team, or a new, separate team?
- What will it cost, and what will it do to quality and defects?
- What cheaper options have we tried first: scope, staging, focus, removing blockers?
If you cannot answer these clearly, the safer decision is usually to fix the plan before you grow the team.
The bottom line
People are not interchangeable units of effort, and time is not something you can buy back by the head. A late project needs a diagnosis before it needs a bigger team. Sometimes more people are the right answer, early, on divisible work, in a separate team. Far more often, the faster route is less work in progress, a sharper scope and an honest plan. Nine months is nine months; good project managers plan for it rather than pushing on the hourglass.
Sources
- Brooks, F. P., Jr. (1975; anniversary edition 1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Open Library record
- "Brooks's law." Wikipedia, summarizing Brooks (1975, 1995); Hsia, P., Hsu, C. & Kung, D. (1999), "Brooks' law revisited: a system dynamics approach"; and McConnell, S. (1999), "Brooks' Law Repealed," IEEE Software. en.wikipedia.org/wiki/Brooks's_law
- Effectiviology. "Brooks' Law: Adding Manpower to a Late Project Makes It Later" (communication channels n(n−1)/2). effectiviology.com/brooks-law
- "Ringelmann effect." Wikipedia, summarizing Ringelmann (1913) and Ingham et al. (1974). en.wikipedia.org/wiki/Ringelmann_effect
- QSM (2025). "4 Key Studies on Team Size" (Putnam 1997; Beckett 2006; Armel 2012; Putnam 2018–2019). qsm.com/blog/2025/4-key-studies-team-size
- QSM (2012). "Top Performing Projects Use Small Teams." qsm.com/blog/2012/top-performing-projects-use-small-teams
- Cohn, M. "The Just-Right Size for Agile Teams," Mountain Goat Software (Hackman and Vidmar's 4.6 finding). mountaingoatsoftware.com
- Coutu, D. (2009). "Why Teams Don't Work" (interview with J. Richard Hackman). Harvard Business Review, May 2009. PDF copy
- Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. scrumguides.org/scrum-guide.html
- Sterman, J. D. (1992). "System Dynamics Modeling for Project Management." MIT Sloan School of Management. mitmgmtfaculty.mit.edu
- University of Waterloo Project Management Office. "Schedule Compression" (crashing and fast-tracking). uwaterloo.ca
- Electronic Design. "Is It Always a Bad Idea to Add Resources to a Late Project?" electronicdesign.com