The diminishing return of adding personnel to a task April 24, 2007
Posted by Wille in Management, Software Development.trackback
The knee-jerk reaction to time pressure in orthodox project management tends to be adding personnel to a task. The theory goes that additional resources will help getting a task done quicker.
However, a lot of the time this tends to be a false assumption. It is especially true in software projects, but probably equally true for other types of projects of intellectual endevour.
Simply stated, there is a diminishing return to added resources to a task of a given size and scope. There is even a point where the return of added resources will actually become negative. In other words, for any given task there is an optimum number of people which will give the best end results.
This is such an obvious fact that it should really be taught at “project management ABC”, but it doesn’t seem to be taught anywhere. At all.
The reason for the diminishing return on adding resources is quite simple: the overhead in communication and coordination increases faster than the productivity of adding people.
If there are three people working on a task, there are three possible routes of communication. If you add a fourth there are six possible routes of communication. For each added person, the number of possible routes of communication increase by the number of total participants – 1. At some point the added effort in coordinating and communicating will surpass the actual productivity added to the effort of getting the task done, hardly an optimal solution.
Another often stated statistic at least within software development is that the best people can be up to ten times as productive as someone of average skill (I would presume this again applies almost equally well to other intellectual pursuits).
Considering this, and the stated relationship between adding people and increased communication complexity and overhead, there should be an extremely strong case for opting for smaller, highly skilled teams rather than large teams of average- to low skill.
When it comes to inherently “intellectual” work, such as software development, the preference of having lots of cheap, lower skilled personnel rather than fewer more expensive and skilled people can turn out to be an expensive mistake to make.
Given the already comparable low productivity of lowly skilled people, combined with the further drag on productivity of high coordination and communication overhead, having fewer and more highly skilled people will end up being cheaper by leaps and bounds, even if you pay them twice or three times what you pay a “cheap” employee!
When it comes to intellectual work, the blind pursuit of cutting cost and timelines by having large teams of lower skilled people in preference of smaller teams of higher skilled people can best be described as blind folly.
“Adding people to a late project makes it later.”
Fredrick Brooks, 1975
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
It is being taught. I had a course in software engineering at TUHH, Hamburg, Germany, where I was taught exactly this. There even was some “magical” formulas (several different) we learnt which had info on what the typical team size would be depending on project size and complexity. However, the formulas weren’t the same as your and not at all as bad as your parallel post implies (Microsoft wouldn’t even have released Windows 2.0 if that formula was even remotely correct). Still there was a point where adding people would be countereffective. If you know German, these slides from the relevant lecture will be highly informative: http://www.sts.tu-harburg.de/~r.f.moeller/lectures/se-ss-04/04-Aufwandsschaetzung.pdf
Magnus: with regards to the formula, I’m no mathematician, I just posted the formula my mathematician friend provided.
Although I don’t think it is that bad conceptually, even though it may not be scientifically exact, it illustrates the phenomena. And depending on your inputs, the numbers will vary wildly..
As for this being taught: yes, it might be taught in some of the more engineering or mathematics oriented educational institutions, but in my experience, very few project managers, at least here in the UK come from those types of backgrounds. Having had a brief spell with Accenture as a permanent employee once, I can tell you their project management practices and internal education/resources see the relationship between resources and productivity as strictly linear: just throw more warm bodies at a problem and it will get solved, thats their theory at least.
Your mathematician friend should have noted that it is O(n!), basically, it grows out of control very quickly. Especially if you consider that with n+1 people, you could just start by telling the last one “we’ll pay you but you don’t need to do anything, just browse the web on your computer to look like you’re doing anything”…
Second: “not being taught anywhere – at all” is very far from “not being taught to Accenture project managers”. It doesn’t surprise me att all that it isn’t being taught to them actually. To be a bit mean to them – they probably don’t understand anything more complicated then a simple linear relationship, and even if they do, they need to be able to compare the project sizes. Measuring how big a software project is not an elementary task – there are several methods to try which emphasize different aspects, which give different results and not even researchers agree on which is best – because that is dependant on in which context you use them. The lecture slides a linked earlier introduce some of these.
Magnus: there are reasons i gave my notice in disgust after only two months as a permanent employee..
Unfortunately as a contractor, I’ve seen exactly the same “rationale” in many other organizations..
I understand you did. Even though I don’t agree with the formula you supplied (it’s too pessimistic – even though it’s bad in reality it’s not quite THAT bad), all the rest of what you wrote is perfectly valid (and it’s also said in the book Erik mentioned). Just seems like the knowledge about it really hasn’t spread outside the world of software engineers…