Kevlin Henney’s keynote at GOTO Copenhagen this year discussed how project time varies as a function of the number of people on the project. The most naive assumption is that the time is inversely proportional to the number of people. That is
t = W/n
where t is the calendar time to completion, W is a measure of how much work is to be done, and n is the number of people. This assumes everything on the project can be done in parallel. Nobody waits for anybody else.
The next refinement is to take into account the proportion of work that can be done in parallel. Call this p. Then we have
t = W[1 – p(n-1)/n].
If everything can be done in parallel, p = 1 and t = W/n as before. But if nothing can be done in parallel, p= 0, and so t = W. In other words, the total time is the same whether one person is on the project or more. This is essentially Amdahl’s law.
With the equation above, adding people never slows things down. And if p > 0, every addition person helps at least a little bit.
Next we add a term to account for communication cost. Assume communication costs are proportional to the number of communication paths, n(n – 1)/2. Call the proportionality constant k. Now we have
t = W[1 – p(n-1)/n + kn(n-1)/2].
If k is small but positive, then at first adding more people causes a project to complete sooner. But beyond some optimal team size, adding more people causes the project to take longer.
Of course none of this is exact. Project time estimation doesn’t follow any simple formula. Think of these equations more as rough guides or metaphors. It’s certainly true that beyond a certain size, adding more people to a project can slow the project down. Kevlin gave examples of projects that were put back on track by reducing the number of people working on them.
My quibble with the equation above is that I don’t think the cost of more people is primarily communication. Communication paths in a real project are not the simple trees of org charts, but neither are they complete graphs. And if the problem were simply communication, then improved communication would mitigate the cost of adding people to a project, though I imagine it hardly does.
I think the cost of adding people to a project has more to do with Parkinson’s Law which says that people make work for each other. (The aphorism form of Parkinson’s Law says that work expands to the time allowed. But the eponymous book explains why work expands, and it is in part because people make extra work for each other.)
I wrote about a similar theme in the blog post Maybe you only need it because you have it. Here’s the conclusion of that post:
Suppose a useless project adds staff. These staff need to be managed, so they hire a manager. Then they hire people for IT, accounting, marketing, etc. Eventually they have their own building. This building needs security, maintenance, and housekeeping. No one questions the need for the security guard, but the guard would not have been necessary without the original useless project.
When something seems absolutely necessary, maybe it’s only necessary because of something else that isn’t necessary.
8 thoughts on “Optimal team size”
Here is Dr. Neil Gunther’s thought on optimal team size based on queueing theory, which as you’ll see also has the n(n-1) terms for coordinating between n people on a team. It was an interesting application of Neil’s Universal Scalability Law.
Just wanted to mention another approach to enable more accurate estimate of project completion is using the project completion time distribution of your organization and Probability, as advocated in the non-prof Probability Management http://probabilitymanagement.org/index.html.
There is also the problem that the person that is the best fit for the job is hired first and then each subsequent employee hired is more likely to be a lesser fit (unless the employment pool is vast/time scale is long or those employing the workers are really terrible at their job).
Off the quantitative bits on this response.
Based on my 20 years of working in corporate America, the best team, in terms of getting project done on time and within budget, gets immediately disbanded right after their success, because that very team made every other team looked bad. The batting average for this phenomena is 3 for 3 in my case.
I’ve always treasured the occasions when I happened to be a member of such a fantastic team, because it is a rare occurrence, just like getting a good teacher in a public high school, which is less than the fingers of my hands. Wish I had been more thoughtful in my youth and thank these fantastic teachers.
I think one important part of the equation that is missing is the gains from specialization. The other side of the coin would be the complexity of the project in terms of the variety of skills that are needed.
The formula t = W[1 – p(n-1)/n + kn(n-1)/2] can be applied for estimation running time of an algorithm on parallel cores.
Typo near “as before”? t=W/n