Resource Allocation and the Law of Diminishing Returns

Transcription

1 esource Allocation and the Law of Diminishing eturns Julia and Igor Korsunsky The law of diminishing returns is a well-known topic in economics. The law states that the output attributed to an individual unit of input diminishes with each additional unit of input, hence the term diminishing returns or diminishing returns on investment. Since ancient times people learned that planting too many seeds leads to poor harvesting results, i.e. one cannot indefinitely increase the input to further increase the output. As our life becomes more complex we apply this ancient knowledge to multiple aspects of life. Computer scientist Gene Amdahl has demonstrated applicability of diminishing returns to parallel computing. Amdahl developed a formula to calculate the optimal number of parallel CPUs needed for large calculations. He illustrated that acceleration is constrained by the part of code-execution that runs sequentially, and thus maximum overall time improvement is finite and can be calculated (estimated). Allocation of human resources can be approached in the same way as hardware resources. Adding people to a project will result in time improvement for project s concurrent tasks, but the law of diminishing returns kicks in due to the existence of sequential tasks. This article provides IT Project and esource Managers with a quick rule of thumb in estimating the optimal resource allocation for large projects. We use Amdahl s formula and apply it to a hypothetical project to analyze maximum possible time improvement. We then enhance the formula to take project overhead into account. We illustrate the impact of fixed project overhead to the project s time improvement. We also look into the more realistic scenario of having variable overhead. In doing so, we will illustrate the concept of saturation point - a point after which adding resources to the project becomes counterproductive, decreasing the overall project completion time. Example Let s imagine a large software project to be completed by a single software developer. Let s assume that developer works 00 percent in isolation completing the project within certain time. It may be sensible to add more people to speedup project development. The question is: How many? We all know that project will not be finished proportionally faster to the number of added resources. The overall time improvement will be affected by the existence of tasks that cannot be parallelized. If we ignore other factors (for now), and in a way pretend that people are machines, the overall project development time improvement ) can be calculated using well-known Amdahl s formula: ) P + P In the above formula, P is a fraction of work that can be parallelized; is the total number of resources. In all examples that we showing in this article we are going to assume that 90 percent of all tasks can be parallelized, i.e. P.

2 ) + Table below provides results ) for of our calculations for {5, 0,, 65}: esources () (I) Incremental Time (ΔI) Table. A Classic Case of Diminishing eturns The data in the Table illustrates a classic case of diminishing returns every 5 people (unit of input) has lesser and lesser impact on the Incremental Time s ΔI (unit of output). If, then ΔI 0 as illustrated on a graph bellow (Figure ) (I) Incremental Time (ΔI) Figure. A Classic Case of Diminishing eturns Analysis of the above dataset leads to a conclusion that total time improvement I is a finite number. For example, if 000,

3 000) In fact, with P when, I 0 as demonstrated in formula below lim lim Above calculations illustrate that regardless of the number of resources added to the project the maximum possible time improvement is 0, given the 90 percent parallel tasks. Example 2 In real life the potential for the s will be smaller than in the Example. The more people are being added to the project, the more new tasks are being introduced to make sure people work cohesively more status meetings, more code sharing and more documentation, coordination and new discussions. Thus, we propose to adjust Amdahl s formula by taking into account the Total Overhead O due to the human factors: O ) ( + O P) + P 0 Let s continue with our example project in which we could parallelize 90 percent of the tasks. In a simplified case let s assume that project s overhead is a fixed number, regardless of the number of resources working on a project. Let s assume that fixed overhead is 0 percent (O 0.). As in a previous example, we are going to calculate ) for {5,0,, 65}: esources () (I) Incremental Time (ΔI) Table 2. The for 000

4 In addition to the data in Table 2, let s calculate the for 000. Wwe intentionally took such a large number of people to further illustrate the law of diminishing returns. As shown below 000) is equal to ) ( + 0. ) Comparing results with the first example, it is evident that an overhead has an impact on the Total Time ). The maximum improvement for this example is shown below: 0. ( + 0. ) lim lim (I) Incremental Time (ΔI) Figure 2. Negative Effect of Overhead The data set in Table 2 and Figure 2 illustrates that the is negatively impacted by the project s overhead. However, shapes of the above curves (I and ΔI) are not affected by the overhead. Example 3 Let s make our example even more realistic. It is reasonable to presume that a larger team has a larger overhead and that overhead consists of a fixed part not affected by the team s size and a variable part that will grow as the team grows. Note that in real life the variable overhead is even harder to calculate it may grow incrementally, increasing with each new resource or resemble a step-curve. For the purpose of our demonstration we are going to show the case where variable part is proportional to the amount of resources. The overall overhead is a sum of fixed overhead (o) and growing variable part ( k ), where k is a coefficient of overhead per person, O o + k Our modified formula looks as following:

5 o + k ) ( + o + k P) + P Let s assume a 0 percent fixed overhead o and each person adds 50 basis points to the fixed overhead, i.e. k For 5 people the total overhead O If we plug in 0 in the above formula, then ) (see below) ) ( ) + 0 If we plug in 000 in the above formula, then ).73 (see below) ).73 ( ) These results (for 0) and 000)) paint a different picture for the ). In the two prior examples, if < 2 then ) < 2 ). However, this is not the case since we introduced a variable overhead in our current example. We can conclude that a variable portion of the overhead has a significant impact on the total time improvement and thus 0 people achieve better result than 000 people. To generalize this observation, the limit of ) is calculated below: 0. ( + 0. ) lim lim When we plugging in the numbers into our formula with the same P and {5, 0,, 65} we get the following values of I and ΔI: esources () (I) Incremental Time (ΔI)

6 Table 3. Too Many People Slow a Project Down Incremental Time Figure 3. The Saturation Point Table 3 and Figure 3 demonstrate something that experienced managers already know too many people will slow a project down rather than speeding it up. Adding people are beneficial only to a certain point after which the overall time improvement decreases we will call this point a saturation point. In the current example the saturation point is reached at 6 (sixteen people). If we continue adding people, incremental time improvement ΔI becomes negative and I decreased. Conclusions Overall time improvement I from all three examples is shown on the in Figure (I) 2 (I) 3 (I) Figure 4. Times form All Three Examples The law of diminishing returns applies to projects resource management and Incremental Time ΔI attributed to each additional resource diminishes with each new resource.

7 tasks. Projects I is always a finite number due to the existence of sequential The upper bound of the total time improvement I can be quickly estimated based on the Amdahl formula. That number can be further refined with our proposed formula that takes project overhead into account. If project overhead grows with the number of project resources, then the overhead has a negative impact on the I. Growing overhead brings a project to a saturation point, a point after which adding resources increases the overall project time rather than decreasing it. About the Authors Julia Korsunsky is a senior technologist with emphasis in database architecture. For over 20 years Julia has consulted clients from start-ups to Fortune 500 companies designing and implementing systems, performing business analysis and project management for financial, utilities, biomedical and pharmaceutical industries. She created and taught IT training courses at Clark University and written articles, manuals and curriculums on a range of technical subjects. She holds two Masters Degrees, in Mathematics (with minor in education) and Computer Science. Julia can be contacted at [email protected] Igor Korsunsky is a senior manager with over 20 years of diverse IT experience in finance, banking and healthcare. Igor is experienced in IT planning, budgeting, and technical and business analyses, systems and workflow architecture. Igor holds two Masters Degrees in Manufacturing (minor in automation) and Mechanical Engineering. He can be contacted at [email protected]