Why adding more people to a late project makes it later
“Adding manpower to a late software project makes it later.” Brooks’ Law, from Fred Brooks’ 1975 book “The Mythical Man Month.” The book is nearly 50 years old and still describes exactly what I watch happen on consulting projects.
As a consultant, I’ve seen this play out more times than I can count. A project falls behind, the client panics, and someone decides the solution is more people. What follows is almost always a mess.
Brooks’ Law, briefly
Software development doesn’t scale with headcount. Neither do most complex consulting projects. When things go sideways, our instinct is to throw more bodies at the problem. That instinct is usually wrong.
A few reasons why:
- New team members need time to understand the project, the codebase, and the business context
- Existing members have to stop doing actual work to onboard them
- Communication overhead grows fast as teams get bigger (with n people, potential communication channels = n(n-1)/2)
- Some tasks are just sequential. You can’t get a baby in one month with nine women.
The consulting version of this
These problems get worse in consulting. I once joined an ERP implementation that had grown from seven consultants to over twenty. Six months behind, burning money. The client’s answer was to add more consultants.
By the time I arrived, basic decisions were bouncing between specialists and workstreams for weeks. Team meetings needed a room for forty people.
What makes consulting particularly prone to this:
- Clients often equate headcount with progress
- Fixed deadlines with contractual penalties push everyone toward visible action
- Knowledge ends up concentrated in a few people, so newcomers can’t really help
- High billing rates require constant justification
What actually works
When a project is late, more people is usually the wrong answer.
Cutting scope is often the most effective thing you can do. Figure out what has to ship and push everything else to a later phase. That alone can buy enough breathing room to get back on track while still delivering something the client can trust.
Before adding resources, find the bottleneck. On a cloud migration project, environment provisioning was grinding the whole team to a halt. The client wanted six more engineers. We brought in one DevOps person who automated the provisioning process. Unblocked the entire team in days.
If you do add people, add them for a specific problem. A focused SWAT team that knows exactly what it’s there to fix is much less disruptive than five generalists who need a month to ramp up.
Talking to clients about it
This is the hard part. Clients see more people as progress. Explaining why you want to reduce the team takes real effort.
On that ERP project, we eventually cut the team to twelve, clarified who could make which decisions, and tightened the scope. The project shipped in four months, faster than the projected timeline with the larger team.
One last thing
“The bearing of a child takes nine months, no matter how many women are assigned.” Brooks wrote that in 1975.
Some things just take time. The best move is usually to find the one or two changes that actually unblock people, rather than filling the room with more of them.