Why Adding Resources Doesn't Always Help

Apr 02, 2008
by:   Tim Stanley

Those who've read the book The Mythical Man-Month: Essays on Software Engineering know the mantra Adding manpower to a late software project makes it later.  But why does it make it later?  How many resources should you put on a project to optimize the delivery date?  How do you explain and justify to the customers and teams the optimal number of resources to be on a project?  How do you explain that adding more than the optimal resources won't make the delivery date sooner?  Resource saturation is my answer.

Optimal Delivery Date And Optimum Resources

I started with a simple premise for planning project.  Something that was a known size, I could add as many resources as possible, but the delivery date needed to be as soon as possible. I don't often get offered unlimited resources, so I was intrigued with the plan.  Some assumptions I noted for estimation.

  • The scope was 24 man months effort
  • The lowest granularity of the work is one month
  • There are no critical path dependencies between 24 work items
  • There is zero ramp up time for adding a resource to a project
  • There are no vacations, sick time, or holidays
  • 1-24 resources could be added
  • Optimize delivery calendar time
  • 10% communication time between team members (four hours per week)

Adding resources to a project helps initially.  Once the team reaches a certain size, the amount of time saved by adding an additional resource has very little impact on the delivery time.  I used a factor of 10% of the time per resource spent in just communications (e-mail, meetings, discussions or interactions with other members of the team).  That number is likely too low compared to an average organization and likely unrealistically low for large organizations which have a significantly higher communication overhead, but for the initial optimization of resources, it doesn't really affect the optimum number of resources by a significant amount of calendar time.  I built a simple spreadsheet to do the calculations.  My spreadsheet had more detail, but hopefully you get the idea.

  • 1 resource, 24 months
  • 4 resources, 6.4 months
  • 6 resources, 4.6 months
  • 8 resources, 3.4 months
  • 12 resources, 3.2 months
  • 16 resources, 3.1 months

We can see that four resources instead of one cuts the time to 25% of the original 2 calendar years.  Six resources, cuts it to about four months and two weeks.  Eight resources, cuts it down to three months and two weeks.  From there, it takes an additional four resources (for a total of twelve) just to bring the delivery date in one week earlier (3.2 months).  Doubling our eight resources to sixteen only saved two weeks on the calendar time delivery.  What happened?  We hit resource saturation.  I put together the image below to show what resource saturation looks like and how adding resources affects the project time it takes to complete the work.

Resource vs Time

Resource Vs Time

Resource vs Time showing resource saturation above eight resources.

If only 10% of developer time was spent in communication, by the time we hit 10 resources, we had the equivalent of one full time person doing nothing but communicating.  That causes and interesting thing to our costs.  As we add resources, we are adding communication to the team.  That adds costs, which goes up non linearly.

Resource vs Cost


Resource Vs Cost

Adding more than eight resources didn't affect our delivery date by more than two weeks, but adding more, certainly increases our costs.  Optimizing both resources and costs gives us a a good range for planning.  I've rounded the numbers up to the nearest week.  This is the type of information that we might need to present to a team or a customer.  This doesn't take into account vacations, sick time, or holidays, but it does give a rough number for resource planning and allocation.

  • 6 resources for 4 months and 3 weeks
  • 7 resources for 4 months and 1 week
  • 8 resources for 4 months

We now have enough data to logically explain planning questions.

  • How long do we anticipate the project to take?  Approximately 4 months with 8 resources or 5 months with 6 resources.
  • Can the project be completed in two calendar months? No, regardless of the number of resources, the full scope can not be complete in two months.
  • Can the project be completed in three calendar months? It may be possible, but it's unlikely it can be completed in three months.

The most significant thing that can be done to improve the delivery time is to prioritize the features and delivery less feature and function in a shorter time and then follow with a subsequent release with the remaining function.  The next most significant thing that will affect the delivery date is the injection of overtime.  While I'm not a fan of using overtime for planning, once resource saturation occurs a 10% increase in time can shorten the delivery date because it doesn't typically add an increase in ramp up time or an increase in communications to the team.  Planning more than 10% overtime over any extended period of time is unsustainable and unrealistic planning.

Adding Resources Makes a Project Later

We found an optimal number of resources, and an optimal time and delivery date, but I still haven't answered the question, why does adding resources make a late project later?  Once resource saturation is achieved, adding resources to a project underway does two things.

  1. It Increases the amount of time that an existing team member must spend in explaining what has been done already and what is planned.  This increases the overall communication time spent by the team.
  2. It increases the amount of ramp up time that a resource must spend on learning what has been completed already.

I was reminded of this both by prompting from a customer and by an article Jeff Atwood wrote on Revisiting The Facts and Fallacies of Software Engineering.

The model I show doesn't exactly simulate adding resources to a late project, but it does show what happens when communications is increased.  Instead of having 10% communication, what if we increase the model to 33% communication overhead, what happens?

Resource Vs Time With 33% Communication

Instead of decreasing the time to delivery, it actually takes more time.  24 resources take the same amount of time as 3 resources.  After resource saturation, adding resources makes projects later.

Related Items