Why Adding X Resources doesn't cut time by X

9 pregnant women can't make a baby in a month.  
 
In Software Development projects, being able to accurately estimate how long a task or group of tasks to complete a deliverable will take, is far from easy. The efficiency of this is a product of how much information is provided, how many people are working on these tasks, and the estimators previous experiences (knowledge of technical complications and political intricacies).  
 

But in my experience, 9 out of 10 times, adding an extra resource to split the workload and cut the time required in half doesn't always play out in the way a team would expect. Here are a few rules I've learned over some time.  
 

There's a limit on how much you can refine a project into distinct pieces to assign to more programmers.  
 

Splitting the project among more people means more integration as we'd have to figure out how each piece fits together. There are also more requirements to communicate/coordinate.  
 

For every person added to the project, this is another node of communication which slows things down (or can). There's a curve when you add each new member, where existing productive resources have to spend time getting new people up to speed that they otherwise could have spent working on the project.  
 

Ultimately you may increase capacity but temporarily it slows down the project. This means it's probably not the best idea to add people to a last minute project, if it's absolutely not required.  
 

A good adage for this is  
 

A well run kitchen can make a lot of meals in parallel, but there's a limit as to how fast it can make a single meal without under cooking or burning it.  
 

Below is an exercise by Jeff Atwood, which presents a bunch of questions that demand you to provide a range. For example:  
 

Don't make your ranges too narrow or too wide, but be sure they're wide enough to give you a 90 percent chance of hitting the correct value, the point of this exercise is estimates, not the right answer.  
 

https://blog.codinghorror.com/how-good-an-estimator-are-you/  
 

The results on the next page in the exercise showed that most people's intuitive sense of "90% confident" is really comparable to something closer to "30% confident."  
 

We are conditioned to believe that estimates expressed as narrow ranges are more accurate than estimates expressed as wider ranges. We believe that wide ranges make us appear ignorant or incompetent. The opposite is usually the case.  
 

Take home message:

People are naturally hesitant to provide wide ranges - even when the confidence level requires a wide range to be accurate - because they feel that narrow estimates are a sign of a better estimate. Your estimate probably should be wider than you made it.

September 9, 2019

Project Delivery