Human resource selection for software development projects using Taguchi’s parameter design

Human resource selection for software development projects using Taguchi’s parameter design

European Journal of Operational Research 151 (2003) 167–180 O.R. Applications Human resource selection for software deve...

354KB Sizes 0 Downloads 2 Views

European Journal of Operational Research 151 (2003) 167–180

O.R. Applications

Human resource selection for software development projects using TaguchiÕs parameter design Hsien-Tang Tsai a, Herbert Moskowitz


, Lai-Hsi Lee



Department of Business Management, National Sun Yat-Sen University, Kaohsiung, Taiwan Krannert School of Management, Purdue University, West Lafayette, IN 47907-1310, USA Department of Information Management, National Pingtung Institute of Commerce, Pingtung, Taiwan b


Received 16 January 2002; accepted 30 July 2002

Abstract Resource selection for choosing a best project team at the planning stage of a software development project is an important issue for reducing project cost, duration, and risk. Based on a real data retrieval software project, two cases of the software resource selection problem for single and multiple specialties under a dynamic, uncertain environment are considered and modeled. We then propose an integrated, efficient computational method based on design of experiments to solve the software resource selection problem, in which a critical resource diagram (CRD) is first used to show the interrelationships among human resources and tasks, followed by implementing TaguchiÕs parameter design approach to select appropriate human resources. In TaguchiÕs parameter design, human resources are identified as controllable factors while task complexities, which are generally unpredictable, are regarded as noise (uncontrollable) factors. The results show that our proposed approach is an efficient and effective method for human resource selection, which can achieve robust performance as well as significantly reduce project cost and duration. Moreover, use of CRDs in concert with a project planning table provides useful visual information, for example, to earmark bottleneck activities for attention, as well as cost information for budgeting management and control. Ó 2002 Elsevier B.V. All rights reserved. Keywords: Resource selection; Critical resource diagram; Project management; Parameter design

1. Introduction Evidence reveals that the failure of software development projects is often a result of inade-


Corresponding author. Tel.: +765-494-4421; fax: +765-4949658. E-mail addresses: [email protected] (H.-T. Tsai), [email protected] (H. Moskowitz), [email protected] (L.-H. Lee).

quate human resource project planning. Such planning involves determining what task is to be done by whom, and the timeline for developing and implementing the software system. Prior research has focused on optimizing a product schedule assuming a preassigned set of human resources. However, little attention has been given to the issue of human resource selection of a best software development project team at the planning stage. This is the motivation of our research and for the development of an efficient, implementable

0377-2217/$ - see front matter Ó 2002 Elsevier B.V. All rights reserved. doi:10.1016/S0377-2217(02)00600-8


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

human resource selection method for software development projects. Human resources in software projects require a high level of individual intensity devoted to project design tasks, which then need to be integrated collaboratively among the software designers to complete the project. Human resourcesÕ technical skills and implementation experience are key factors for project success and therefore must be allocated and managed judiciously. The following four human resource characteristics and tasks in software development projects therefore deserve serious attention: (1) Resource scarcity: Human resources in a software development project require not only technical skills but also knowledge and experience related to the project. Such qualified people are usually a scarce resource and therefore there is considerable competition for their services among and within multiple projects. (2) Resource heterogeneity: Human resources for software development possess varying strengths and abilities such as technical skill, education, and experience, which impact project performance, cost, and cycle time. The success of a project is highly sensitive to the capability and diversity of the assigned human resources. (3) Resource non-substitution: Human resources are targeted and assigned to tasks by matching them to the technical skills and experience required for their successful and timely accomplishment. A task is then performed and completed by an assigned human resource not only using the skills and experience required, but also through continuous learning occurring on the project task. Accordingly, any substitution or rotation of a resource often results in ÔforgettingÕ and ÔrelearningÕ, resulting in prolonging the project duration and increasing project cost and risk. (4) Task variation: A quick and accurate assessment of the completion time of tasks is important in order to schedule a project successfully. However, task complexity in a software development project is not easily anticipated or measured, since software programs may be implemented using different system architectures,

languages and software tools, which increase the uncertainty of a taskÕs completion time. This is the realistic type of dynamic, uncertain project environment that is considered throughout the manuscript. A human resource can be selected to take on one job that consists of several project tasks based on their similarity. Generally, human resources are limited for a certain type of job that requires different specialties. For example, a job involving data communication requires a human resource with skills in computer networks. Furthermore, human resources and project tasks in software development projects are highly interdependent. The relationships between human resources and project tasks form a complex network, which makes it difficult to determine which job should be undertaken by whom. Abdel-Hamid (1989, 1993) concluded that scheduling and resource allocation strategies in one project could significantly influence the performance, cost, and the duration of projects. Effective project management can thus be achieved only if interdependencies, requirements, and priorities are managed at appropriate levels. Resource selection for software projects includes the following two major issues: (a) depicting the workflow of the project to show interactions within and among human resources and tasks, and (b) determining the method of selecting proper human resources. The workflow relationships among project tasks and human resources are often described by graphical scheduling tools, which can be classified into several categories: (1) traditional project scheduling tools such as a Gantt chart, critical path method (CPM), and program evaluation review technique (PERT) networks; (2) network project scheduling diagrams, such as Petri-net (Petri, 1962), design net (Liu and Horowitz, 1989); (3) dynamic models that monitor a project from a system dynamic perspective (Abdel-Hamid, 1989); (4) critical resource diagram (CRD) (Badiru, 1992, 1993). Among these approaches, the first three categories focus on the flow planning of activities. A CRD, however, takes a different perspective by focusing on resource scheduling rather than activity scheduling, so that

H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

the workflow among resources (rather workflow on activities) can be observed. Since a CRD can visually demonstrate the status of human resources in a software development project, it is adopted as the visual scheduling tool of choice throughout this manuscript. The concept of parameter design as proposed by Taguchi (1986) is a useful and important approach for product and process improvements. Applications of this concept in practice have shown that it not only provides the tools for exercising sound engineering judgment but also lasting solutions to complex problems as well as accelerating learning within new technology. Lautenschlager et al. (1995) employed TaguchiÕs parameter design concept to analyze trajectories of NASA space vehicles, and concluded that parameter design is also more efficient than Monte Carlo simulation. Santell et al. (1992) applied TaguchiÕs parameter design to project management in which a simple PERT/CPM model was used to trade off resources. This suggests that TaguchiÕs parameter design concept could be a useful approach for selecting proper human resources for software development projects and thus provides, in part, a rationale for its application. This motivated us to propose and develop an integrated approach to human resource selection involving a CRD to show the interrelationships among human resources and tasks, and TaguchiÕs concept of parameter design to obtain an optimal, robust, and practical allocation scheme for human resources planning of software development projects under dynamic, uncertain conditions, such as task complexity.

choosing the proper set of human resources to form a software development team to accomplish the project at minimum cost and cycle time. With many projects ongoing simultaneously and limited human resources, the III was searching for a systematic method for human resource selection to maximally assure that project cost and cycle time would be minimized. An example of a data retrieval software project at the III is used to illustrate our proposed approach to the resource selection problem of forming a best project team. The company contracted with a government department to develop a judicial retrieval system that would collect entire judicial documents into a full-text retrieval database, where judiciaries could retrieve related judicial documents from the system to facilitate their legal tasks. The retrieval system was constructed using a client/server architecture, where a data request typically involves querying data located on a server through user interface software (Fig. 1). The retrieval system was coded in C language, and can be classified into the following software components: (1) Database interface (DBI): provides software objects for software applications in the server side to access or maintain the retrieval database. (2) User interface (UI): offers display functions for PC-client applications. (3) Data communication interface (DCI): provides basic control functions for data communication.

2. Project description 2.1. Software project from III The Institute of Information Industry in Taiwan (III) is a software company founded by the government, and is well known for its software products. Being a leading software company, it deploys many project teams to carry out various software development projects. At the stage of initiating a software project, a project manager has to develop a sound project plan, which involves


Fig. 1. The framework of the client/server project.


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

(4) Application programs interface (API): provides software components for data connection of application programs at both the server and client sides. (5) Application programs (AP): includes application programs of query and data maintenance at both the server and client sides. The programs of query and data maintenance at the server side, denoted as Qs and Ms respectively, will call the functions of the DBI by the request command from the client side. The programs of query and data maintenance at the client side, denoted as Qc and Mc respectively, receive requests from the UI to API. 2.2. Job, task, CRD workflow All software components (or tasks) in the judicial retrieval project can be aggregated into three major jobs having the following associated tasks: Job I is to construct the retrieval database involving tasks DBI, Ms and Mc; Job II is to construct the user interface including UI, Qc and Qs; Job III is to develop data communication between the server and clients, involving tasks DCI and API. Three human resources, denoted as resources A, B, and C are needed for Jobs I, II and III, respectively. In addition, system integration would be a shared, collaborative effort by all three human resources. The task assignments for the three human resources are summarized in Table 1. To present the interrelationships among human resources and tasks, a CRD (Badiru, 1992, 1993) is employed to depict the workflow of the project, as shown in Fig. 2. Each node represents a task responsibility (e.g., DBI) for a given human resource ðAÞ to be accomplished in time ti . Software components (tasks) DBI, UI, and DCI are three basic functions of other software components, and are designed initially by human resources A, B, and C, Table 1 Task assignments for three human resources Resource







Mc Qs Integration

Integration Integration



A t1

A t4



C t2

C t5



B t3

B t6

Mc A t7



A+B+C t9

B t8

Fig. 2. The CRD of the client/server system project.

respectively; API must be developed immediately after DCI to support the needs of data communication but before Mc; Ms needs to be developed before Qs and Mc; Qc can be designed immediately after UI but before Qs. The final task of system integration (involves human resources A, B, and C simultaneously) occurs after tasks Mc and Qs are completed. A human resource may appear at more than one node if there are no time or task conflicts (Fig. 2). For example, three tasks are assigned to resource A at different points in the project sequence. The duration of the ith task (days) denoted by ti is given. From this, the earliest and latest start and finish times can be easily computed for each node via a standard PERT/CPM analysis, and the critical path determined. Namely, those human resources having no slack time, form a critical resource path, and the critical time duration (critical path) is the estimated total completion time.

3. Data and design 3.1. Capabilities and requirements Selection of the human resources for the judicial retrieval project was based on the capabilities and salaries of the available pool of candidates. As the three major jobs required different skills and techniques, the project manager searched available human resources by their specialties, and initially

H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180


Table 2 Working capabilities and costs of human resources in three jobs for Case I Job

Skill level 1

I: DBI þ Ms þ Mc þ Integration II: UI þ Qc þ Qs þ Integration III: DCI þ API þ Integration a

Skill level 2 a

A1 (200, 1800) B1 (200, 2000) C1 (100, 1900)

A2 (350, 2300) B2 (400, 2400) C2 (150, 2500)

Denotes (R ¼ work rate: number of code lines on average per day, P ¼ payment: NT$ per day).

selected six available human resources. More specifically, each major job had two possible candidates, denoted as human resources A1 and A2 for Job I, B1 and B2 for Job II, C1 and C2 for Job III, respectively. Given the candidate set, the project manager was required to select one out of two candidates for each major job to form a threemember project team. The work assignment, capabilities, and salaries of the available six human resources are summarized in Table 2. Work capability is measured by the expected work rate denoted by ðRÞ, which is the expected code lines a human resource can execute per day; the salary denoted by ðP Þ is the average salary in NT$ (the local currency) of a specific human resource per day. For example, A1 can write RA1 ¼ 200 code lines on an average per day and his/her payment is PA1 ¼ 1800 NT$ per day. Task complexity is not easily anticipated or measured and is thus treated stochastically. To do so, the project manager must estimate the average lines of code required to accomplish the task under varying possible task complexity environments. Following PERT, an optimistic (low complexity), normal (most likely complexity), and pessimistic (high complexity) estimate of average code lines

for each task are obtained to reflect the three possible task complexity environments, denoted as levels 1, 2, and 3, respectively. Table 3 shows these estimates for the eight functional tasks in Table 1 (or Fig. 2), denoted as factors S to Z (does not include the integration task). Namely, the average code lines of each task for varying unknown conditions of task complexity are denoted by Cij , i ¼ S; . . . ; Z and j ¼ 1; 2; 3. For example, CS1 ¼ 7500, CS2 ¼ 8500, and CS3 ¼ 9500. The components DBI and Qc have higher average code lines than the other tasks, because of their greater difficulty. The data communication components DCI and API have fewer code lines than other components since their basic functions can be extracted from other existing data communication platforms. So far, we have (a) represented task assignments using a CRD to depict human resource workflows and precedent constraints, and (b) defined project resource and task capabilities and requirements, which incorporate stochastic elements to capture the uncertainty of task complexity. We now introduce and apply TaguchiÕs concept of parameter design to select human resources for the judicial retrieval software development project.

Table 3 Optimistic, normal, and pessimistic estimates for average code lines of each taska Factor


Level 1(Optimistic)

Level 2(Normal)

Level 3(Pessimistic)



7500 1500 5000 6000 1500 8000 1500 1000

8500 2500 6000 6500 2500 9000 2500 2000

9500 3500 7000 7000 3500 10,000 3500 3000


Estimates reflect the possible different levels of task complexity that may be encountered in the project.


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

3.2. Taguchi’s parameter design TaguchiÕs concept of parameter design can be partitioned into two factor sets: an inner array containing the controllable factors and an outer array containing noise factors. Both inner and outer arrays can employ either factorial or orthogonal arrays depending on the size of a problem. The inner array is designed to facilitate the optimization of controllable factors, while the outer array is to efficiently draw information on the joint effect of noise factors in order to achieve robust results. Thus, TaguchiÕs parameter design is not only used to determine the optimal conditions of the engineering parameters (controllable factors) but also to minimize variation of the noise (uncontrollable) factors. The signal to noise (SN) ratio provides a measure of robustness, and its formula for ‘‘the-smaller-the-better’’ characteristic is given by " # n 1X 2 SN ¼ 10 log y ; ð1Þ n i¼1 i where yi is the project cost or duration of each CRD network (Peace, 1993). The larger the SN ratio, the greater the degree of robustness. We next need to identify the controllable and uncontrollable (noise) factors of the project. For the judicial data retrieval software system, the three human resources are regarded as controllable factors, each having two levels that represent the two possible candidates from which to choose from to perform a given task. A full factorial design with 23 ¼ 8 treatments (candidate–human resource combinations) is employed as the inner array, since this is a small number of combinations. The eight software components (or tasks) are regarded as the noise factors (S to Z) with three levels each since the degree of their complexity is uncertain. Due to the larger number of possible task-complexity levels (38 ¼ 6561), an orthogonal array is preferred to a full factorial design in the outer array, in the interest of computational efficiency. A L81 orthogonal array is suitable for this case, in which lines 1, 2, 5, 10, 12, 13, 14, and 27 are selected as the columns of the eight noise factors by the first linear graph in Peace (1993). The

Fig. 3. Layout of TaguchiÕs parameter design.  1 and 2 denote the candidate skill levels for human resources A, B, and C.

resulting layout of TaguchiÕs parameter design is shown in Fig. 3. 3.3. Project goals The desired goal or improvement metrics in our software development project is defined as the total project cost and project duration, which has ‘‘the-smaller-the-better’’ characteristic, and therefore (1) can be applied. Namely, the objective is to minimize both project duration and total project cost, where total project cost is composed of the total human resource and tardiness costs; i.e.,  Pn Pj  D þ F  ðD  dÞ; if D > d; PC ¼ Pj¼1 n if D 6 d; j¼1 Pj  D; ð2Þ where PC is the total project cost; Pj , the salary payment of resource j per day; D, critical duration of the project; d, deadline of the project; F , delay cost per day. Since all human resources are dedicated fulltime until the project is completed, the jth human resourceÕs cost is calculated by Pj  D. Therefore, with n human Pn resources the total resource cost is given by j¼1 Pj  D. In this case, the delay cost is equal to F ¼ NT$10,000 per day if the project is not finished before the targeted deadline of d ¼ 120 days.

H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

vidual with multiple specialties/skills can handle several jobs.

The duration of the ith task denoted by ti is equal to the average code lines of the ith task Ci in Table 3 divided by the associated work rate Ri in Table 2, to yield the following times for the activities in Fig. 2: t1 ¼ CS =RA t4 ¼ CV =RA t7 ¼ CW =RA

t2 ¼ CT =RC t5 ¼ CZ =RC

4.1. Case I: One specialty per resource For this case, each human resource is considered to have only one specialty, each job has two possible candidates, and information on the productivity and salary of the six candidates are summarized in Table 2. This yields two levels of three controllable factors (Table 2) and eight noise factors (Table 3), resulting in TaguchiÕs parameter design layout shown in Fig. 3. Considering all combinations of the inner and outer arrays, the design layout has a total of 8  81 ¼ 648 different CRD networks, each with an easily computable project cost and duration. When all factors, for example, are at the first level, say A1 B1 C1 for the controllable factors and S1 to Z1 for the noise factors, the corresponding CRD network and its project cost are shown as in Fig. 4. The first step for obtaining the project duration (critical path) is to calculate the duration of each node; for example from Tables 2 and 3, t1 ¼ 7500=200 ¼ 37:5 days. Then following the standard method as in PERT, the resulting project

t3 ¼ CU =RB t6 ¼ CX =RB t8 ¼ CY =RB

t9 ¼ ðCS þCT þCU þCV þCW þCX þCY þCZ Þ =ðRA þRB þRC Þ The time duration for the system integration task is computed as the total average code lines divided by total work rate for all human resources. The critical path can be obtained by the standard method used in PERT.

4. Analysis and results Motivated by the actual situations faced by the III, the following two cases are considered: (a) Case 1. . . there are six candidates and each has only one specialty/skill to perform on one job; (b) Case 2. . . there are five candidates and one indi-


DBI A t1=37.5




A t4=30


67.5 A t7=7.575




15 C t2=15

C t5=10

A+B+C t9=64


Qs 25

UI B t3=25

B t8=7.5

Qc B t6=40

72.5 Total Project Cost =NT$982,300

25 65


Project Duration =139days

Fig. 4. The resulting statistics of the CRD with all factors are at first level.


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

Table 4 Project statistics for the eight treatments in Case I Run

1 2 3 4 5 6 7 8


1 1 1 1 2 2 2 2



1 1 2 2 1 1 2 2

1 2 1 2 1 2 1 2

Project cost ($)

Duration (days)


Standard deviation



Standard deviation

1,484,797 1,470,337 1,119,486 1,143,391 1,201,962 1,218,220 683,907 684,651

140,898 140,375 132,332 133,705 155,561 157,396 64,971 35,739

)123.47 )123.39 )121.04 )121.22 )121.67 )121.79 )116.74 )116.72

171.01 163.82 144.07 140.31 148.27 143.93 103.28 95.09

8.97 8.61 8.22 8.05 9.60 9.40 8.93 4.96

duration (critical path) and project cost are 139 days and NT$982,300, respectively. In Fig. 3, all 648 response data (i.e., for each CRD network) of project duration and project cost can be computed in the identical way. Using the standard analysis associated with TaguchiÕs parameter design, for each treatment in the inner array the average project cost, standard deviation of project cost, SN ratio, as well as the average project duration and standard deviation of 81 observations are computed and summarized in Table 4. The tardiness penalty heavily affects the average project cost. For the first six treatments in Table 4, their average durations exceeded the deadline of 120 days and consequently roughly doubled the average project cost as compared to when the deadline was not exceeded. Only two treatments

A2 B2 C1 and A2 B2 C2 (treatments seven and eight) among the eight treatments had an average duration shorter than the deadline of 120 days. Treatment A2 B2 C1 achieved the lowest average project cost (¼NT$683,907), while A2 B2 C2 yielded the shortest average duration (¼95.09 days). The NT$744 difference of average project cost between these two treatments was statistically insignificant, as was the SN ratio. The project cost standard deviation of A2 B2 C2 , however, was almost half that of A2 B2 C1 (NT$64,971 vs. NT$35,739), while the average project duration of A2 B2 C2 was 8 days less than that of A2 B2 C1 (¼ 103:28  95:09). Hence, treatment A2 B2 C2 is preferred; namely, assign resources A2 B2 C2 to constitute the project team. Table 5 shows the response table for the software project, which is a standard tool of TaguchiÕs parameter design concept. The main effect of a

Table 5 The response table of Case I Factor

Project cost ($)

Duration (days)




Standard deviation

A1 A2

1,304,503 947,185

)122.28 )119.23

154.8 122.6

8.46 8.22

A1  A2





B1 B2

1,343,829 907,859

)122.58 )118.93

156.7 120.7

9.14 7.54

B1  B2





C1 C2

1,122,538 1,129,150

)120.73 )120.78

141.7 135.8

8.93 7.76

C1  C2





H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180


Table 6 Project statistics for the six treatments in Case II Run




Project cost ($)

Duration (days)


Standard deviation



Standard deviation

1 2 3 4 5 6

1 1 1 1 2 2

1 1 2 2 1 1

1 2 1 2 1 2

1,484,797 1,470,337 1,119,486 1,143,391 1,146,256 1,169,413

140,898 140,375 132,332 133,705 152,694 154,516

)123.47 )123.39 )121.04 )121.22 )121.26 )121.43

171.0 163.8 144.1 140.3 143.9 140.2

8.97 8.61 8.22 8.05 9.40 9.23

Note: A2 is replaced by B2 .

factor is defined as the difference between the average values of the two levels (i.e., A1  A2 , B1  B2 , C1  C2 ). Then the main effect of factor A is given by A1  A2 ¼ NT$357,318 and A2 is the recommended condition. For the average project cost, SN, the average duration, and the standard deviation of duration, the main effects of resource A are thus equal to (NT$357,318), ()3.05), (32.2) days, (0.24) days; for resource B (NT$435,970), ()3.65), (36.0) days, (1.6) days; and for resource C (NT$6612), (0.05), (5.9) days, (1.17) days, respectively. Therefore, for resource A and B, employing a higher skilled resource would achieve robust results such as a lower average project cost, higher SN ratio, and a shorter average project duration. For resource C, a higher skill would only slightly increase the average cost (¼NT$6,612), negligibly affect the SN ratio (0.05 increase), reduce the average duration (¼5.9 days), and reduce the duration standard deviation (¼1.17 days). 4.2. Case II: Multiple specialties for some resources In Case I each human resource had two possible candidates. Often this is not realistic. Instead, another resource may be skilled in several specialties. For example, suppose A2 is no longer available (e.g., he/she is on sick leave, left the company), but resource B2 has multiple skills that can be substituted for A2 . Referring to Table 2, all conditions remain the same except that A2 can now be replaced by B2 . However, if B2 takes on all tasks of both resources A and B, then only two human resources would be included in the project (viz., B2 B2 C1 , or B2 B2 C2 , for jobs I, II, and III, respectively). The CRD would need to be revised ac-

cordingly, resulting in an increase in the expected project duration. To eliminate this situation, the treatments of A2 B2 C1 and A2 B2 C2 (runs 7 and 8 in Table 4) are thus excluded in the inner array, resulting in only six possible treatments (Table 6). The computational results for Case II show that all project durations of six treatments exceed the project deadline, resulting in tardiness penalties. Treatment A1 B2 C1 exhibits the lowest average project cost, lowest standard deviation of project cost, and the highest SN ratio. Moreover, treatment A1 B2 C1 Õs average project duration exceeds A1 B2 C2 by almost three days, while its average project cost is NT$23,905 less. 4.3. Cases I vs. Case II A performance comparison of the ÔoptimalÕ allocations in Case I (A2 B2 C2 ) vs. Case II (A1 B2 C1 ) is shown in Table 7. 1 Case IIÕs average project cost increased by 63.5%, the standard deviation of project cost by 270%, the SN ratio decreased by 3.7%, the average project duration increased by 51.5%, and the standard deviation of project duration increased by 65.7%. In sum, both the average and variation in performance of the above metrics across treatments were considerably better for Case I than for Case II. Note that there were no really good options available in Case II as there were in Case I (namely, runs 7 (A2 B2 C1 ) and 8

1 ÔOptimalÕ is based on the sample of 81 out of a possible 6561 (¼38 ) combinations of outer array scenarios. To determine a true optimal, all 6561 outer array combinations would need to be evaluated.


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

Table 7 Case I Vs. Case II optimal performancea Case

Optimal treatment

I II Difference (II  I) Difference (II  I)/I (%)

A2 B2 C2 A1 B2 C1

a b

Duration (days)b

Cost ($) Average

Standard deviation



Standard deviation

684,651 1,119,486 434,835 63.5

35,739 132,332 96,593 270.0

)116.72 )121.04 )4.32 )3.7

95.09 144.07 48.98 51.5

4.96 8.22 3.26 65.7

Performance data for Case I obtained from Table 5. Target date is 120 days.

(e.g., treatment A1 B2 C1 for Case II); in particular to individually examine their critical paths in order to obtain further insight on the most likely project duration and its possible variation, as well as duration of each task and resource to identify potential bottlenecks for continuous improvement or immediate, corrective action. To illustrate, consider the 6  81 ¼ 486 response data sets in the parameter design of Case II, each representing a CRD network with different conditions of human resources and tasks. For each treatment in the inner array, there are 81 corresponding combinations of noise factors (scenarios) in the outer array, such that the selected treatments can be evaluated with respect to their robustness to task complexity. Table 8 shows that for treatment A1 B2 C1 there exists only two possible critical paths among the 81 CRDÕs evaluated; namely, DBI–Ms–Mc-integration (72 CRDÕs) and DBI–Ms–Qs-integration (9 CRDÕs), the former path being eight times more likely to occur (¼72/9) than the latter. The latter

(A2 B2 C2 )). Simply put, in this project, the unavailability of A2 requiring use of B2 with multiple skills as a substitute, seriously degraded project performance. Prior knowledge of the estimated magnitude of the degradation in project performance, for example, could have possibly been used as a benchmark and early warning for considering additional options, such as deciding whether to outsource or subcontract, how much to pay for subcontracting, or to create overtime services to substitute or compensate for the missing resource. Our proposed approach easily allows for such comparisons to be made apriori, to anticipate surprises, and facilitate evaluation of various possible options in determining an appropriate allocation and risk-hedging strategy or contingency plan. 4.4. Critical path analysis It would be prudent to analyze the 81 CRDs associated with the optimal resource allocation

Table 8 Case II costs and duration of the critical paths for A1 B2 C1 Path

Cost ($)

Duration (days) DBI






Mean N Standard deviation

1,127,313 72 133,044

42.5 72 4.1

32.5 72 2.1

13.1 72 3.9

56.4 72 3.2

144.6 72 8.3


Mean N Standard deviation

1,056,875 9 123,491

42.5 9 4.3

32.5 9 2.2

8.8 9 0

56.4 9 2.7

140.2 9 7.7

H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

path will become critical only when task Qs is under the pessimistic task complexity condition (3500 code lines). The standard deviation of duration for task Qs is thus equal to zero under this condition. Ignoring the integration task, the human resource involved in these two paths is A1 (except for task Qs). The average duration of tasks conducted by resource A1 is 42.5 days for DBI, 32.5 days for Ms and 13.1 days for Mc. Obviously, resource A1 is the bottleneck of the project; namely, the project duration can be decreased by increasing the productivity of resource A on either or all of its tasks (DBI, Ms, or Mc), for example, by working overtime or through just-in-time training. 4.5. Project planning with Gantt chart In conjunction with our approach, the Gantt chart or planning table, which depicts task resource allocations, assignments, scheduling, duration, and costs provides another useful visual tool to facilitate management of a software development project. Consider again optimal treatment


A2 B2 C2 for Case I, which is represented in Table 9 under conditions of normal task complexity (Table 3). Its critical path under normal task complexity is DBI–Ms–Mc-integration, with duration of 93.9 days. Prior to the integration task (43.9 days), resource A1 is expected to take 50 days to accomplish tasks DBI, Ms and Mc; resource B2 is expected to take 43.8 days for tasks UI, Qc and Qs; resource C is expected to consume 30 days for tasks DCI and API. Thus, both resources B and C have slack times of 6.2 (¼ 50  43:8) days and 20 (¼ 50  30) days, respectively. The project manager may thus consider assigning tasks on other projects to resource C in particular. A cost analysis for each task can also provide additional information for budgetary planning and control. 4.6. Orthogonal array justification The parameter design we used in our illustrations was a full factorial design in the inner array for three controllable factors and an orthogonal array L81 in the outer array for eight

Table 9 Planning table of A2 B2 C2 under normal conditions for case I Resource




24.3 18.6

55,890 42,780






























Duration (days)

Cost ($)

6.18 6.44 0.24 0.37 0.00 0.00 )6.32 0.20 )0.99 )1.03 0.00 0.00 0.00 0.00 )6.00 )1.39 9.06 8.70 8.22 8.05 9.60 9.40 9.50 5.03 )0.09 )0.09 0.00 0.00 0.00 0.00 0.08 0.14 171.00 0.01 163.81 0.01 144.07 0.00 140.31 0.00 148.27 0.00 143.93 0.00 103.37 )0.09 95.00 0.09 )0.01 )0.01 0.00 0.01 0.00 0.00 )0.03 0.01 0.00 0.00 0.00 0.00 0.00 0.00 )0.02 0.01 )123.47 )123.39 )121.04 )121.22 )121.67 )121.79 )116.76 )116.71 Diff1: 100ðL81  FullÞ=Full (%); Diff2: 100ðL27  FullÞ=Full (%).

1 2 3 4 5 6 7 8

1 1 1 1 2 2 2 2

1 1 2 2 1 1 2 2

1 2 1 2 1 2 1 2

1,484,635 0.01 1,470,169 0.01 1,119,486 0.00 1,143,114 0.02 1,202,017 0.00 1,218,007 0.02 685,130 )0.18 683,999 0.10

)0.96 )1.00 0.00 )0.56 0.05 )0.36 )7.15 )1.23 142,270 141,797 132,332 134,463 155,482 157,969 69,976 36,185 )0.15 )0.16 0.00 0.07 0.00 0.05 )0.18 0.13

6.17 6.41 0.29 )1.46 0.05 )1.12 )12.72 0.33

Diff2 Diff1 Full Diff2 Diff1 Full Diff1

Diff1 Full Diff2 Full





Average duration (days) SN Standard deviation Average project cost ($NT) ABC

noise factors. An orthogonal outer array is employed here to reduce the number of experiments and computing time. In order to justify the performances of orthogonal arrays in the outer array (i.e., less than full factorial designs), an orthogonal array L27 in which lines 1, 2, 5, 8, 9, 11, 3 and 6 are selected by the first linear graph in Peace (1993) as well as a full factorial design with 38 ¼ 6561 treatments were performed for comparisons against the L81 orthogonal outer array for Case I. Then the total number of experiments will be 8  27 ¼ 216, 8  81 ¼ 648, and 8  6561 ¼ 52,488 different CRD networks, for L27 , L81 , and a full design, respectively. The performances such as average project cost and its standard deviation, SN ratio, as well as average duration and its standard deviation for the results of the above three designs are summarized in Table 10. To facilitate the comparisons, the full design is used as a base; diff1 ¼ 100ðL81  FullÞ=Full (%) and diff2 ¼ 100ðL27  FullÞ=Full (%) are denoted for L81 and L27 , respectively. Both the L81 and L27 designs yielded the same optimal treatment as the full factorial design. Moreover, it is clear that the performance of a L81 is superior to that of a L27 , with the performances of average project cost and duration being more accurate than that of their standard deviations. For example, diff1 is within 0.18% while diff2 is within 0.18% of true average project cost; diff1 is within 0.09% while diff2 is within 0.14% of true average project duration. In terms of the SN ratio, diff1 is within 0.02% while diff2 is within 0.03%, which is quite good. However, the standard deviation of cost for diff1 and diff2 are 7.15% and 12.72% respectively, while the standard deviation of duration are 6.00% and 7.68% respectively. In sum, these results indicate that the use of a fractional design such as an L81 is effective and considerably more computationally efficient than a full factorial design. Moreover, higher order fractional designs such as an L27 can be effective as well. Note that the sizes used here are 27 ¼ 3ðm=21Þ and 81 ¼ 3ðm=2Þ , where 3 is the number of levels for each noise factor and m ¼ 8 is the number of noise factors in this project. Therefore, an orthogonal array of size 3ðm=2Þ or less will often be sufficient for an outer array design.

Standard deviation

H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

Table 10 Performances of L27 and L81 vs. full design in outer array for case I


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

5. Summary and conclusions Based on a data retrieval software project from the Institute of Information Industry in Taiwan, two cases of a resource selection problem for single and multiple specialties under an uncertain task complexity environment were considered. A computationally efficient, integrated method was proposed to solve the problem based on design of experiments, where a CRD is used to show the relationship between human resources and tasks, and then human resources are selected using TaguchiÕs parameter design that are robust to task complexity. In TaguchiÕs parameter design, human resources are regarded as controllable factors while tasks of uncertain complexity are represented as noise or uncontrollable factors. The metric for task complexity is the total number of written code lines, each estimated under optimistic, normal and pessimistic conditions of complexity. Selection of human resources to form a project team is based on optimum and robust performance; namely, minimizing project cost and duration while simultaneously displaying robustness (insensitivity) to the uncertainty of task complexity (minimize variation of performance metrics to task complexity). Furthermore, a critical path analysis of the CRDs and a Gantt chart or planning table provide additional visual information for managing projects. Our experience in formulating and applying our approach to the judicial retrieval project in the III demonstrated its efficiency and visual effectiveness for resource selection, analysis, and contingency planning of small software development projects. A nice feature of applying TaguchiÕs parameter design approach to resource selection is that the response data (of project cost and duration) are easily computable and exact, rather than requiring experimental simulation, which is more laborious and subject to experimental error. Moreover, when a full factorial design in the inner array is employed, a confirmation run is unnecessary. For large scale problems, an orthogonal array might be needed for the inner array as well as the outer array, and the standard Taguchi procedure including a confirmation run has to be applied in order to obtain an acceptable solution. For the


outer array, an orthogonal array with size of 3ðm=2Þ or less is sufficient, where m is the number of noise factors. In sum, our approach shows promise for relatively large as well as small scale projects by employing fractional designs (orthogonal arrays) for both the inner and outer arrays. But this needs to be more intensively explored to assess the appropriate array sizes to optimally balance accuracy against computational efficiency. Some additional issues for future research include: 1. Incorporate quality as well as cost and duration as performance metrics in our methodology. 2. Contrary to the other software development tasks, systems integration is a true team/collective effort, involving considerable human interaction and cooperation. Our approach aside, how should this activity be estimated and managed? 3. How can we apply TaguchiÕs parameter design approach to multiple projects; e.g., where individuals are (a) assigned full-time across a menu of projects, or (b) assigned part-time to several projects simultaneously?

Acknowledgement The research was supported by National Science Council of R.O.C., under grant no. NSC 87-2416-H-110-017 to National Sun Yat-Sen University, Kaohsiung, Taiwan.

References Abdel-Hamid, T.K., 1989. The dynamics of software project staffing: A system dynamics based simulation approach. IEEE Transactions on Software Engineering 15 (2), 109– 119. Abdel-Hamid, T.K., 1993. A multiproject perspective of singleproject dynamics. Journal of Systems Software 22 (3), 151– 165. Badiru, A.B., 1992. Critical resource diagram: A new tool for resource management. Industrial Engineering 24 (10), 58– 59,65. Badiru, A.B., 1993. Activity-resource assignments using critical resource diagramming. Project Management Journal 24 (3), 15–21.


H.-T. Tsai et al. / European Journal of Operational Research 151 (2003) 167–180

Lautenschlager, U., Erikstad, S.O., Allen, J.K., Mistree, F., 1995. Experimental satellite trajectory analysis using decision-based robust design. Journal of Guidance, Control and Dynamic 18 (5), 1126–1132. Liu, L.C., Horowitz, E., 1989. A formal model for software project management. IEEE Transactions on Software Engineering 15 (10), 1280–1293. Peace, G.S., 1993. Taguchi Methods: A Hands-on Approach. Addison Wesley, Reading, MA.

Petri, C., 1962. Communication with Automa, Ph.D. Dissertation, University of Bonn, Bonn, West Germany, 1962. Santell, M.P., Jung Jr., J.R., Warner, J.C., 1992. Optimization in project coordination scheduling through application of Taguchi methods. Project Management Journal 23 (3), 5– 16. Taguchi, G., 1986. Introduction to Quality Engineering: Designing Quality into Products and Processes. Asian Productivity Organization, Tokyo, Japan.