Why adding more people to a project doesn’t make it go faster

At no point in an IT project I have seen time made up without removing large parts of functionality. The common reaction to a project failing behind is to add more people to it but Brook’s law reminds us

“adding manpower to a late software project makes it later” Federick Brooks

This article will look at the reasons adding more people to a project does not speed it up and sometimes could slow it down.

My experience

I worked on a project with two scrum teams with 4 Dynamics developers in each team. The project was progressing, but the teams could have been working more efficiently. The plan was to continue to improve the output but the client doubled the scrum teams from 2 to 4 teams. This slowed down the 2 teams and the project.

Onboarding the 8 new developers took 2 months, this needed people from the existing teams to knowledge share and answer questions about processes and functionality. The onboarding meant we had 2 slow teams and the two previous teams slowed down as they answered questions from the new developers. The increase communication between 4 teams took more effort and was not always effective. The increase in work attempted, needed the teams to work closely because functionality overlapped between the team, this often caused functionality to not work or bugs to appear.

On the same projects an integration team and data migration team of 8 people joined, the new additions had a minimal effect on the existing teams.

This article will look into the reasons to explain why adding more people can slow down a project and why sometimes it doesn’t.

Project estimation

IT projects are not a place you can make up time, the more likely scenario is it takes more time than you estimated. Estimates are done using high level requirements which lack details of the required solution, when the details become clear they add more time to the project. Estimates are optimistic and assume no problems will happen on a project (technical problems, people leaving, slow decisions, no SME’s, etc), the result is estimates are underestimates.

The bidding process effects estimates on a project, usually the lowest bid wins because it seems the cheapest but not all bids are equal. Sometimes the lowest bid misses parts of the solution like DevOps, testing or people from the team. During the project the missing requirements pop up and have to be paid for.

Cost should not be the deciding factor because IT projects are long-term investments where quality, expertise and experience of delivering on time should be considered. 

Do you want to build the solution fast or do you want to build it right?

The reasons you can’t make up time because the common method to making up time, involves adding more people to a project, which brings Brook’s law . Brook’s law can be outrageously simplified to these reasons

1. It takes some time for the people added to a project to become productive. Brooks calls this the “ramp up“ time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
2. Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3] Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
3. Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other’s way). However, other tasks including many specialties in software projects are less divisible; Brooks points out this limited divisibility with another example: while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.

The key reason to why adding more people doesn’t make a project go faster is new people need to onboard onto a project. It takes 1 or 2 months for someone to become fully productive, they slow down the fully productive people working on the project. The initial effect of adding more people onto a project is to slow down the original team, this may be short-term pain for longer term gain, except this isn’t factored into adding more people onto a project. It results in not making the project quicker, but adding more cost.

What the adding more people plan fail to take into account is

• Solution dependency
• Complexity
• Communication overhead
• Leadership

Solution dependency

Solutions consist of multiple customisations, many dependent on other customisations. e.g. you can’t create a login page without setting up the web server and database to save the user details and passwords.

You can’t scale people on a project if the functionality is sequential or has dependencies and the work involves developers overlapping. When you create multiple customisations and/or integrations concurrently, teams will conflict and overwrite each other’s changes. 

The assumptions individuals make can be incorrect, creating bugs which are found in integration tests.

I have seen small scale examples of Dynamics professionals working on the same entity and updating forms, plugins, workflows and Javascript at the same time. The customisations overwrote and when tested produce unexpected results. What would have taken one person 1 day to create the customisations, took 2 people 3 frustrating days.

Try to imagine assigning a team of individual to write a fiction book, each writing a different chapter. The difficultly of splitting up the book into each separate chapters that depends on the chapters before it, makes it almost impossible to write all the chapters at once.

Complexity

Solution complexity increases when you have multiple customisations working together that are dependent on each other or interact. You need to design the whole solution and separate developers to create individual components and understand the whole solution.

Adding more people to a project is effective if the solutions are not interdependence. The more complex the solution, the harder it is for multiple developers to work on related customisations at the same time. The more integrated the solution, the greater the complexity and the slower multiple developers work.

Individuals creating customisations have to understand how the business works and how the whole solution works. Most individuals in a business usually only understand a small part, its difficult to understand the business, technical solution and how both fit together.

The increased complexity makes testing harder and results in more bugs where a single component is changed without considering the effects on the whole system.

back to writing the book with each person writing a chapter at the same time. The complexity of getting all plots and character arcs with no errors would be challenging.

“As a system becomes increasingly complex, the chance of failure increases. A plan can be thought of as a system. he more components you have, the more chances that something will go wrong in one of them, causing delays, setbacks, and fails in the rest of the system. Even if the chance of an individual component failing is slight, a large number of them will increase the probability of failure.” Shane Parish — Unlikely Optimism: The Conjunctive Events Bias

Communication overhead

The more people you add to a project the more communication and meetings you need to collaborate successfully. Sharing information, getting updates, agreeing on a plan and understanding all the different perspectives will be time consuming.

Any changes in solution design or best practices need to be communicated with everyone on the project.

Communication costs and miscommunication slow down the output on the project.

Leadership

IT Projects are a team sport and good teams need good leaders. It can be difficult to quantify or measure leaders because they don’t create an output. If you have worked on a project with bad leaders you can see the confusion, bad decisions and lower morale to work out the effect.

Adding more people costs more money, adds communication difficulties and increases the complexity of the project. .

Good leaders do

• Empower and encourage other members of the team
• They are umbrella’s — they shield the team from distraction, noise and interference
• They over communicate and keep the team informed
• Push back on the customer when needed
• Manage the different characters
• Give clear direction
• Control the scope
• Solve problems and improve the project
• Listen to people
• Know when to have an opinion
• energise the team and motivate individuals

What good leaders don’t do

• Add lots of people to a project hoping it will make it go faster
• Side with the customer when they are wrong
• Agree to impossible demands
• Sit there and do nothing

Summary

The method commonly used to estimate projects is to split up the work into small focused parts and estimate them separately, no effort to estimate the costs of complexity of the whole solution. 

Communication, leadership, complexity and interdependent development are rarely factored into estimates. Just because it’s difficult to estimate these, its not an excuse for not trying.

The inside view leads us to overestimate our abilities and underestimate the work. Read more Why IT projects estimates are wrong

High-level requirements create high level solutions and these expand in complexity when the lower level requirements are added. Low level requirements can break initial solutions and lead to the project running behind schedule. The common response to this problem is to add more people to a project, this can slow the project down whilst costing more money.

I will leave you with this Fred Brook’s quote

How does a project get to be a year late? One day at a time. Fred Brooks

Related blogs

• To deliver a project on time, stick to out of the box (if you can)
• Conjunctive events bias
• The outside view — how long will it take to create a vaccine for Covid-19?
• How other people can improve your ideas