Let’s say we have a field full of wheat, and we have no automated equipment so the field will need to be harvested manually. This is a fictious example, but we believe demonstrates the concept well. We gather up our friends and commence harvesting and we are, on average, able to harvest 10 bushels per person per day. We need to get the harvest completed by a certain date, so we add a few more people to our work team. We go out into the field and once again, we average 10 bushels per person per day. We add one more person to this harvesting crew, and we have a new rate of accomplishment, an average of 8 bushels of wheat per person per day. We have just encountered the law of diminishing returns.
The law asserts that if equal increments of one variable input are added while keeping the amounts of all other inputs fixed, total production may increase; but after some point, the additions to total product (the marginal product) will decrease.1
In present day, in our experience, this happens very frequently in project management, product development and likely most business endeavors. We are late, so we add more and more people to the work. This is often referred to as crashing the project, or all ‘hands-on’ deck moments.
There are three things that influences the point at which the results of the law will manifest. For example, as the citation above indicates, all other elements must remain fixed. That is, the specific point at which this diminishing return manifest, depends upon all other attributes in the system do not change. Changing the supporting system, can change the point at which the marginal output decreases as the fixed inputs are changed. Remove these constraints, and there will be a new area where the diminishing returns will impact.
The constraints within the system has led to a modern spin off known as the theory of constraints. This theory proffered by Eliyahu M. Goldratt in his book titled The Goal, looks at any stream of work as a sequence of events, and there are points in this system that are capable of handling more of the throughput than others. Therefore, the entire system’s output is restricted by the least capable element in that system. Imagine a water hose of varying thickness or carrying capacity. Consider the “water hose” below. The most constrictive is item C, if we focus on items A or B, the overall system performance will not change, which results in a wasted effort.
If you have ever worked on a project that you find all of a sudden to be way behind the planned or anticipated schedule, and rather than adjust the schedule or ascertain the reason for the schedule variance, you look at deliverables. What parts of the project have been delivered later than expected and why for example? Noteworthy, a large schedule variance (SV) should be seen long before it becomes a large schedule variance. This comes with follow up on the project work, and identifying key metrics of project performance, but that is beside the point.
A typical gut reaction is to add resources or talent, to ‘catch up’. Business leaders (and sometimes project managers) may believe adding talent to a project under stress, will shorten the schedule at the cost of, well, cost. That is not true. Rather than being late and perhaps under or on budget, we exacerbate the problem likely busting the schedule despite our best efforts and busting the project budget.
The idea that it is possible to throw large amounts of talent will solve our schedule woes, flies in the face of this law, yet this happens. In every training event and speaking event that have had anything to do with project management, suggest this to be a common approach to solving the scheduling problems. There are no studies of which we are aware, that suggest this approach ever works, a project behind schedule typically remains behind schedule, unless some change to the scope.
Even if we can eliminate the other constraining factors, bringing new people onto the team and expecting to get that instant increase in throughput. There are four primary reasons this law of diminishing returns does what it does:
- our existing team members must mentor / coach the new team members on how this project works
- not all team members have the same level of domain experience or skill in the area
- more than just the talent (human) dimension must often grow to maintain the same rate (other fixed factors or constraints)
- variation in project delivery factors and the ability to substitute via other project delivery means (outsourcing)
By and large throwing talent (human resources) at a project that is late will not ensure the project to be delivered on time, to the contrary. By throwing everything at a late project, the cost for the project gets out of control. Additionally, sharing or removing resources from other projects will eventually negatively impact those project schedules due to this “robbing Peter to pay Paul” approach to resource allocation. The result is this continuing decay of the engagement of the talent of the organization, rather the talent is dispersed, running from metaphorical fire to fire.
It is far better to monitor variance early and often. In my experience the review of the SPI & Cost Performance Index (CPI) are set up early in the project so it can be shared on status reports. As soon as a variation is revealed, proactive measures should be taken to identify the source and review possible corrective actions. Solving this SV earlier at that moment identified rather than having to initiate a ‘stressful throwing everybody at the problem situation’ which MAY(?) fix this project but certainly will have negative consequences on the baseline budget & resources.
1Truett, L.J., & Truett, D. B. (1998). Managerial Economics: Analysis, Problems, Cases. Thomson South-Western.