Eindhoven University of Technology
MASTER
Modeling the effects of project staffing on software project performance
Kossen, R.C.M.
Award date:
2010
Link to publication
Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration.
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
by
Modeling the effects of project staffing on software project
performance
R.C. M. Kossen
Philips Lighting BV, Bus iness Unit Co n tro ls
Student identity number 063 8559
Eindhoven, August 20 10
In part ial fulfillm ent of the require ments for the degree of
Mast er of Science
Innovation Management
Supervisors:
dr.i r. K.E. ( Kim) van Oorschot, TU/e, IT EM dr. J. M.P. (Josette) Gevers, TU/ e, HPM
ir. W. van Vugt , Reso urce Manager, P hilips Light ing, BU controls
TVE. Department lndustrial Eng ineering & Innovati o n Sciences
Series Master T heses lnnov atio n Management
ARW 2010 IM
Subj ect headings : Proj ect S taffin g, System dy namics, Scrum, Ag ile, Soft ware develo pment
ABSTRACT
T h e o verall effects of di fferent project staffin g decis io ns on the outcome of a Software Development Proj ect are uncl ear, for both theory and practice. T his master th esis designs and develops a dyna mic simulati on model that ana lyzes the e ffect s of various project staffing decis ions on pro j ec t perform ance. The dynamic model ca lcul ates quality. T he model has been developed and applied on a real life Agil e Software deve lopment proj ect using the so call ed Scrum methodology.
After the model was created and validated, several scenarios have been simulated. T he res ults s howed that; ( 1 ) if the tea m was ramped up earli er, project qu ality increased and both, duration and casts decreased by 2 1 % a nd 17% respectively; (2) a llocating se niors in the st artup phase of a pro j ect shoul d have priority over a llocating senior to the final phases of a proj ect; (3) by adding s lack, the project duration w ill hardly increase a nd qua lity will s lightl y increase; (4) by r educing s lack, the proj ect perfor mance w ill be negativ ely intlu enced; (5) if resourc es need t o be allocated to other proj ects when the pro j ect is half way, it was more benefi cia! to alloca te seni ors to another project instead of juniors, due to faster learning characteristics; and (6) the t esters in a proj ect needs to be balanced, too much leads to 'gold pl ating' a nd too few leads to quality loss.
T he model developed was a first vital step towards a multi project model.
PREFACE AND ACKNOWLEDGEMENTS
Thi s master thes i s report i s the res ult of the fin al assignment for my master lnnovati on Managem ent at the Eindhoven University ofT ec hnology. 1 have executed this research in the fi eld of syste m dynamic m odeling in new produ ct developm ent processes at Philips Lighting.
1 wo uld like to tha nk my first supervisor fr om the university, Kim van Oorschot, for her guida nce in the past 9 mo nths. 1 honestly ha ve enj oyed our pleasant collaboration. Thereby, I have trul y benefited from her knowledge and ex perience in th e fi el d of system dynamic model ing and new product deve l opment. Furthermore, l would like to th ank m y seco nd supervisor fr om the uni vers ity, Josette Gevers for her s upport during this res earch.
1 also woul d lik e to thank my dail y sup erv i sor, Wiec her van Yu gt. 1 s in cerel y appreciate our wee kly meeting we had. Thank yo u for keeping m e m oti vated and providing me the opportunity to do this research within a corporate environment.
Obviously, I a l so would like to thank the who l e Am anda Software Deve l opment team; Ferdinand, Fred, Jack, Joos, Martijn, Michi el, Peter a nd René. Thank you for the pleasa nt working envi ronment and helping me during my research.
Special thanks to my girlfriend, Sanne, for her incredible support durin g m y resea rch. Finall y, I would li ke to thank my famil y and fri ends fo r their l ove and s upport during my studi es.
Remco K osse n
August 2010
EXECUTIVE SUMMARY
INTRODUCTION
Philips Lighting 1 s the g lobal market leader with recognized expertise
inthe development, ma nufacture, and application of innovative lighting so lutions. Business unit (B U) Controls is responsibl e for providing products to g ive peo ple and compan ies the power to seam less ly manage and contra! their lighting. To keep their competitive advantage, Philips needs to develop new products a t an increased pace and under good economie co nditions. Therefore, managing new product development (NPD) processes effectivel y and efficiently is one of the critica! success factors to separate the winners from the losers. And because human resources swa llow up t he greater part of financial resources when it comes to NPD projects, it is vital to manage project effectively and efficiently.
RESEARCH QUESTION
Many companies, however, struggle with efficient manage ment of their workforce, since res ourc e portfolio and proj ect portfolio are very much interre lated. To provide ins ig hts into the effects of diff erent project staffing decis ions, the following research question has been investigated during this master thesis proj ect.
What are the ejjècts ofdifferent project staffing decis ions on project performance, in terms of casts, duration, and quality in an Agile Software Development project?
The goal of effective staffing decisions is to allocate people as such that the overall project performance will be nefit. lnherently, there is a trade-off between proj ect quality, pro j ect duration and project casts. And when a research question involves a tens ion or trade-off among opposing factors, simulation is the favored approach. More specifically, s imulation with System Dyna mics has been
used, because it is capable in addressing dy namics and non-linear co mplex systems.
SVSTEM DYNAMIC MODELING
To analyze a nd answer the research question, a dynamic simulation mode l has bee n developed which is based on a real-life agile software development project. The model included various dynamic behaviors, deri ved from bath theory and intervi ews. Among others these are; hi gher wor k intens ity leads to more errors; more undiscovered rework will degrade downs tream quality; fixing errors casts more tim e; and add ing people toa project wil! decrease team productivity.
Besides these dyna mic behaviors, this thesis combined survey data and r eal project data to create and val idate a model w h ich is abl e to repl icate reality. The survey data helped in quantifying the paramet ers of the simulati on model. And th e real project data (i.e. new a nd reworked lin es of code over tim e, and deadline informati on) were used to assess the reliability of the model.
SCENARIO MODELING AND RESULTS
After the model was developed and val idated, four different situations have developed and simulated.
The first s ituation (utilization of seniors at startup and near the e nd) simulated what would have
happened if t he project team had more manpo wer during the startup phase of the project. It showed that if the team was ramped up ea rlier, it could enhance qua lity by 0 .2 po ints , and cou ld decrease duratio n and costs by 2 1 % and 17% res pectively. A 17% cos ts reductio n stands for a reduction of almost €120.000. T his is dir ectl y o ne of the biggest saving o utcomes of a ll s ituations. T he scenario's also sh owed that a llocating seni ors in the startup phase of a proj ect sho uld have prio rity over all ocating seni or to th e fïnal phases of a proj ect. Adding an extra senior for the first 8 weeks resul ted in an enhancement of project quality by 0.9 points and a decrease in costs of 4%. By adding a senio r at the fïnal 8 weeks of the project, it showed that costs increased by 2% and qua lity got worse by 0.2 points.
The second s ituation (i ncrease or decrease sprint duration) s imulated the effects of increasing the s print duration by 1, 2 and 3 days and d ecreasing it by 1 o r 2 d ays. It showed that by adding minimal slack, an agile proj ect will hardly increase in duratio n, but it does improve quality by 1.1 po ints if every sprint got increased by 2 days. T ighter deadlines, however will negatively intluence performance. lf the sprint got s hortened by 1 d ay, costs s lig htly increase by 1 % and the quality got worse by 1.5 po ints.
The third s ituation ( temporary utili zatio n of resources) modeled the effects of th e tempo rary utilization of resources in the middle of a project by a nother proj ect. Alt ho ug h small differences were v isible, it s howed that it was more beneficia] to t he project if seniors were real located instead of juniors. For example, project costs increased by 0.9% if O .SFTE senio r engineers were utilized fora fou r week p eriod. Costs increased by 1.6% if ajunior eng ineer was utilized by O .SFTE fora fo ur week period. Moreover, the implication on the current project if software testers were reallocated was slightl y s ma ller as when software engineers were reall ocated. For example, the tempo rary utilization of a seni or tester res ulted in a costs increase of on ly 0.4% which compared to the 0.9% for a senior engineer is a little s maller. Also quality got less affected if testers were utilized as when eng ineers were uti lized.
The final situation ( changing quantity and ty pe of testers) mode led fo ur scenarios w ith va rio us types and quantities of software testers. It showed that more testers can s ho rten project duration, increase qual ity, but still increase the proj ect costs. For exampl e one extra senior tester resulted in an enhancement of quality of 1 point, a nd a decrease in proj ect duration by 7%. T he costs however, increased by 6%. F urthermo re, it showed that ifthejunior tester was changed by a senior, it incr eased quality by 1 point, and decreased project duration a nd project costs by 4% and 2% respectively.
MAIN RECOMMENDATIONS
The key implicatio n of this study is that it provides a bas is for managers to think about their proj ect
stafting d ec is io ns. lt showed that allocating seniors in the start up phase of a project s hould have
prio rity over allocating senior to the fïnal phases of a project. Furthermore, managers s hould relax
resource costs s pending during a project, since ramping up a project tea m (whi ch results in hig her
cost s in the beg inning), can tinally lead toa much better proj ect performance in terms of both quality,
duration and costs. And when it concerns agi le d evelopment projects, foc us should be on good
manage ment rather than setting tig ht deadlines. T his research s howed that relaxing th e deadlines a
little, increased qua l ity s 1 i g htly, and hardly increased project du ration. Also, it found that w hen a
project is half way, and reso urces are needed for other projects, it i s more beneficia ! to partially allocate seniors compared to juniors. This i s ma inly due the fact that seni ors are better in switching tasks due to the faster l earning characteristics. Concerning testers, the right balance is needed. If proj ects are simp Ie, fewer testers ca n assure a decent quality. 1-lowever, if proj ects are more complex, or if it is a major platform project, quality is most at stake, which means that there s hould be enough testers to guarantee that quality remains optima! such that downstream quality is not bein g intluenced.
FUTURE RESEARCH
This mode l is the first vital step towa rds a multi-project dynamic model. To ob ta in a high qu ality
multi-project, which can and wil l be used in operations, four different steps need to be taken; (1) th e
m odel should be genera lized for hardware and mechanica! proj ects; (2) the model s hould incorporate
more roles; (3) then an aggregate multi project model can be deve loped which incorporates a project
portf olio and a resource portfolio; and (4) the model should be implemented with a user friendly
interface allowing managers to use the model.
Î ABLE OF (ONTENTS
Abstract ... ... ... " ... ... ... iii
Preface and acknowl edge1nents " .. " .. """"""." " .. """"""""""."""""" .... """."" ... """" ... iv
Executive Summary ... ... ... ... ... ... v
Tab Ie of Contents ... " .... " ... " ... ... " ... " ... " ... """." viii List ofabbrev iations ... " .... " ... " ... """ .... """ ... ... x
lntroduction; dynamic project and resource management""""""""""""""""" .. """""""""""" 1 1 Research Background ... 2
1.1 Four different dynamic interdependenc ies ... " .. ".""" ... ... """""""""""". 2 1.2 Current and missing Knowledge""""""""""""""""""""""" .... " .. "".""" ." " "" " .... """." 3 2 Research Design ... """""""" ... 4
2.1
Research context ... .. . " .. "." .. """ """""" ... "." ... " .... """""". 4 2. 1. l Software deve loprnent " """"""""" """"""""""""""""""""""""""""." ".""""""" 5 2.
1.2The proj ect staffing process "" """"""" ... """ " .. """" ... " ".""."".""""""". 6 2.2 Problern articulation ... .. """""""""""""""""""""""""""" "."" .. ... 6
2.3 Research design ... .... """""""""""""""""""" """""""." .. " .... ... 7
2.4 Dernarcation ... " ... ... """""""."""""""""""".""""""." .... " ... ... 9
2.5 Sun1rnary and outline ... "" ""." """" """"" "" " """"" """ ... ... 9
3 Dynamic Hypothesis """"""""" .. " ... " .... """"" """." ... """"" ... """""" .. "" ... " ... 10
3. 1.1 ldentification process of the dynarnics within BU controls ".""""".""""""""""""" 10 3.2 Custornized Causa! loop diagra111 ... " ... " ""."" """"" .. ... """ ... ... 11
3.2. 1 The rework cyc le ( \ /3)"""""""""""""""""""""" "". """""" " """"."".".".""""". 12
3.2.2 Planning and control (2/3) """"""""""""""""""""""""""""""""" "." ""."""".". 1 3
3.2.3 Other dynarnic effects (3/ 3) """""."." ... ... ... ... "".". 1 4
4 Dynamic Mocleling ... ".""""" .. """.".".""." ... """"""""".". 18
4.1 lntroduction into the casestudy """"." "."""""""""""".".""""""""""""""""""""""" 18
4.2 Data coll ectio n and results""""""""". """"""""""""" .... """"""""""""""."""""""" .. 1 9
4.2. 1 The survey - the people factor """ "."""""""""""""".".".""""""""""".""""""". 19
4.2.2 Empirica! Project data """""".""".""" .. " ... """"" .. """"""""""""""". 24
4.3 The Stocks and Flow Diagram""""""""""""""""""""""""""""""""""""""""""""" 27
4 .3. 1 What is a SFD ".""""""" """"""""""""""""""."""""""""""""""""""""""""" 27
4.3.2 Calculation of project performance""""""""""""""."""""""""""""""""" "" " "" 28
4.3.3 Project staffing " ... " ... .. " """ .. " "" """"""""""""""""""""""""""""""""". "" .... 29
4.3.4 Project base" ... .... ... " ... ... .. """ ... 30 4.4 Testing and validation """"".""""" ... " ... ""." .... """ ... " .. """"". 30 4.4. 1 Mode l testing ... " ... ... " """"."""""" ... " ... " .. " ... " ... " 30 4.4.2 Mode l validation ... """""""" .. """""""" ... " ... "." ... """ .... 32 5 Scenario Analysis ... ... 34 5.1 Situation 1: Utili zation of seniors "" .... "."""" ... """"""""""""" .. """"""""""""""" . 34 5.2 Situation 2: lncrease or decrease sprint duration .. " """"""""""""".".""." """"""" """ " 36 5.3 Situation 3 : Utilization of resources in the middl e of projects """""."""""" """""""""" 37 5.4 Situation 4: The testing effects """""""."" ... """ "."""""""""". " """." """"""""""". 38 5.5 Scenar io conc.lusion """ ... ".""""""""""""" ... """" """""""""" .. """ ... " .. "."""""" 40 6 AppJying the Mode) in Practice ... ... 41 7 Conclusions and Recommendations ... 43 7.1 Conclus ions .... "."." ... " ... """"""" ... """."""" .. ".""" ... ... ""."""""" 43 7.2 Managerial Ins ights and Future Res earch Possibi lities for Philips"" .... """.""".""""" ... 44 7 .2.1 Managerial lns ights ... " ... " ... "." ... " ... "".""" .. "" .. 44 7.2 .2 Future Research Possibi lities for Phi li ps."""""""""""""""" ... " """."""" ... " 45 7.3 Academie Relevance and Recommendations for Further Research"""".""""""""" ... "" 46 8 References ... 48 9 Appendices ... ... ... 51
9. 1 Interview resu lts .... """""""""."""""""" ... """ ... "" .. " ... """"" ... " .. """" .. . 52
9.2 Q uestionnaire results ."".""" ... ... ... 53
9.3 Tof tool programming ... " .. " ... ... " ... "" ... ... ... 68
9.4 Data DSI ... " ... """ ... " ... "." ... " ... """" ... " ... ... .... ... . 69
9. 5 OS I Data C hanges"."""" .... """""""""" .. " ... "" ... " ... " ... ... ... " 73
9.6 Team size Data" .... " ... ... .... ... . " ""." ... """" "" ... ".""."""""""" ... " ... """ 74
9. 7 Optimization strategy ... ... " ... " ... " ." ... . """" ... "" .. """"" ... """"" 83
9.8 Model documentation ... ... ... . " ... " ... . " ... " ... "" ... " ... " .. """ .. " ... 84
9.8. 1 The Staf fin g Compon ent"""""."."" ... " ... """""" """"."" .""" .. ".""""""""""" .. 84
9.8.2 The Agile Development Component".""" """""""""""""""""""""""""""""" "" 86
9.8.3 the rework cycle component """""" ... """" ... "."""" ... """"" ... " ... 87
9.8.4 The Project Costs Component..""""""""""""" ".""."""""."""."""" ... " ... """"". 94
9.8.5 How to run custo m projects ."."""."" " """" " """""""""""""""""" ... """" ... """ ". 94
9.8.6 A ll Othe r Formulas""."""""""""""""""."" ... """ ... " .... . " ... "" .. 95
LIST OF ABBREVIATIONS
BU Bus iness Unit
C LD Ca usa! Loo p Diagram
GBU Global Business Un it
HRM l luma n Resource Management
HW Hardware
PO ew product development
OR Operational Research
SD System Dynamic
SE Software E ngineer
SFD Stoc ks and fl ow Di agram
ST Software Tester
SW Software
LIST OF Î ABLES
Table 1 - S ummary of the A manda pro j ects ... """"."""""""""" .... " ... 19
Table 2 - Part of DS I dataset """"""" ... " ... """"""""""""""""""""" ... ... .. 26
Table 3 - Test results: extreme co nditions test""""""" ... "" .... """""""""""""".""" ... 3 1
Table 4 - Scenario results 1: senior utilization ... """""""""" ... 35
Table 5 - Scena rio results 2; increase I decrease s lack ... """""""""""" .. " " ... " ... " 37
Tab le 6 - Scenario results 3: ut ilization in the M iddle of a proj ect.. """""" " ... " ... ... . """"" . 38
Table 7 - Scenario results 4: C hanging software testers .. """"""""""""" " ... " .. " ... .. .... " 39
INTRODUCTION; DYNAMIC PROJECT AND RESOURCE MANAGEMENT
In today 's co mpetitive envi ronment, l-lig h-Tech co mpani es need to develop new products at an increased pace and under good economie conditi ons. Therefore, managing new product deve lopment (NPD) processes effectively and effici ently is one of the critica ! s uccess facto rs to separate the winners fro m th e losers (Cooper & Kleinschmidt, 1 995; Joglekar & Fo rd, 2005).
Since huma n resources (from now on ca lled resources) swallow up the greater part of the financial resources when it co mes to NPD projects, it is v ita! t o manage project effectively and efficiently (Cooper, Edgett, & Kleinschmidt, 1 999). M any compa nies, however, struggle w ith ef ficient management of their workforce, s i nee resource portfolio and project portfolio are very much interrelated (Abdel-l-lamid, 1989; Engwall & Jerbrant, 2003 ; Repenning, 2000). For exampl e; when proj ects delay, reso urces are la nger allocated to the project, such that succeeding planned projects can not start beca use of the lack of resourc es.
As we will see, resource allocati on dec isions shoul d include the dynamic behav ior of resourc es and proj ects. For this reaso n, this thes is wi ll investigate thi s cutting edge between reso urces and projects.
lt will create practical and theoretica! ins ights in th e dynamic interdependencies between r esources
and projects. It also co mbines t hese insights into a practical useful tool which enables managers to
play with diff erent proj ect staffing strategies. T he model will be a first vital step towards a
multi-proj ect dynam ic environment, to create more effective, efficient, and s uccessful NPD projects.
1 RESEAR CH BACKGROUND
What are the interdependencies between resources and pro j ects? And wha t is currentl y known in literature about these dy nami c relations hips? This c hapter will briefl y a n s wer these two ques tions and hi ghlight s so m e of th e gaps in literature which can be further investigated.
1 .1
fOUR DIFFERENT DYNAMIC INTERDEPENDENCIESThere are numero us dynamic behav i ors within project m a nagement. However, in genera! , we ca n diff ere ntiate fo ur diff erent dy na mic interdependencies (see Figure 1 ).
I . Projects are resource dep endent ; since reso urce ava ilab ility is of utmost importance fo r projects performance. Without resources th ere will be simply no progress in a ny project.
L acking the ri ght or availab l e resources can delay projects signifi cantly. In contrast, havin g a so ca lled ' dream-team' can also accelerate projects dras ti ca lly.
2. Resources are project dependent; since the ava ilabi lity of resources is dependent on th e number of pro j ects executed co nc urrent ly. Bes ides resource availability, resources ca n al s o learn from projects they are or have been executing. They can l earn from prev i ous execute d proj ec ts a nd become more effective in doing future projects. Bes ides learni ng, huma n resources are triggered by m any project characteri sti cs (e.g. schedu le pressure)
3. Projects are dynamic {s ingle project dy namics); s ince project cond itions evo l ve over time, due to exogenous (e.g. customer changes) and endogenous factors (e.g. work crea tes m ore work, du e to rework).
4. Projects are projects dependent (multi project dynam ics); since projects both uti lize resources, reso urces act as a constra int. So, if one project has a sc hedu le overrun, other s ucceeding pro j ects are likel y to have a del ayed start, because of th e l ack of ava ilable reso urces. Further m ore, concurrent pro j ects are often different in type, s ince compani es str i ve for an opti m a ! project portfo lio, which contains a mi x of different type of projects.
Resource portfolio
Resource type A
Project porfol io
FIGURE 1 - BALA CING THE RESOURCE PORTFOLIO AND THE PROJECT PORTFOLIO
1.2
CURRENT AND MISSING KNOWLEDGEM uch is a lready known a bout t he interrelati onshi ps between both portfoli os and much research has been exec uted to optimize the relations hips. However, muc h research is based on a st atie view instead of a dynamic v iew. Es pecially in O peration Research (OR), research is often constra int on s upply (e.g.
resource co nstraint plan ning) or co nstra int on demand (e.g. fixed portfo lio) (Bertrand & Fransoo, 2002; Brucker, Drexl, Mö hring, Neumann, & Pesch, 1999). S uch a statie view o n a proj ect a nd resource portfo li o is not adeq uate since; ( 1) proj ect conditions and performance evolve over time due to feedback responses; (2) proj ects involve man y nonlin ear rela tionships; and (3) du e to th e accumulati on of proj ect progress a nd resources.
To overcome these st atie issues, dy namic s ingle-proj ects mode ls have been developed by several authors to gai n deeper ins ights in t he causa] relationships across variables (Cooper, 1 993; Ford &
Sterma n, 1 998; Lyneis & Ford, 2007; Re ic helt & Lyneis, 1999; Repenning & Nelson, 200 1; Taylor &
Ford, 2006; va n Oorsc hot, Sengupta, Akker mans, & Wassenhove, 2010; va n Oorschot, Sengupta, &
Wassenhove, 2009).
Few however, adopted an holistic a pproach with all t he resource a nd proj ect dyna mics inc luded (Bayer, Gann, & Sa lter, 2006; Rahmandad & We iss, 2009). As Repenning (2000) and Rahma ndad and Weiss (2009) s uggest there is a need for a dynami c approach in resource p lanning. " The most ambi tious directi on for future work is to deve lop large-scale models of m ulti-pro j ect development enviro nments that can he lp managers make resource a ll ocation dec is ions o n an ongo ing bas is"
(Repenning, 2000 p. 207). O nly by allow ing managers to "vis ua lize" the state of their deve lopment processes, a nd t hen ra pidly simulate the outcomes of various interventions, can help to prevent making wrong decis io ns, w hich can enhance overall proj ect perfor mance ( Repenning & Ne lso n, 2001 ).
Moreover, hardl y a ny researchers focused on agile software deve lopment proj ect, which is a popul ar and effecti ve deve lopment standard today. O nly Van Oorsc hot (2009) investigated the effects of different iteration lengths on p erformance. However, these authors did not include reso urce dynamics, as changing team s izes, nor adopted a multi-pro j ect model. Hence, two major gaps in literature can be identifi ed: ( 1) hol is tic multi project dyna mic mode Is; a nd (2) hol is tic dy na mic mode Is w it hin agi Ie development.
Before one can deve lop a large
scal~multi project model, one s hould be abl e to determin e t he
performance of a s ingle proj ect, g iven different proj ect staffi ng characteristics. This is the first
inevita ble step towards a high qua lity aggregate mul ti-project mode l. To make this first step, is th e
goal for this master thesis projec t.
2 RESEARCH DESIGN
Before formulating the actua l research qu es ti on, the context where the resea rch will be executed is being discussed. First an overv i ew of Ph ilips and BU controls will be given. Then the current process of software deve l opment, and allocation processes wi 1 1 be disc ussed.
2.1 RESEARCH CONTEXT
PHILIPS LIGHTING
Philips i s founded m 1891 and is headquartered in Amsterda m, The Netherl ands. lt is one of the l argest global diversified indus trial companies wi th a total of EUR 26,385 million sales in 2008. lt has an international workforce of 118.000 empl oyees (July 2009) and it has sa les outlets in a total of 150 countries. Thcre are manufacturing sites in 28 co untries and Philips has a total R&D expend iture of EUR 1,622 milli on in 2008. Philips group is divided into 4 different sectors; Healthcare, Consumer Lif es tyle, Li ghtin g, and Group manage ment & Services (G M&S).
INTRODUCTION OF PHILIPS LIGHTING
Philips Lighting i s headquartered in Eindhoven, The Netherlands, and is the global market leader, with recognized expertise in the development, manufacture, and appli cati on of innovative lighting solutions. Philips Lighting i s both active in the "upstrea m " light-source bus iness (e.g. Fluorescent, lncandescent, LUXEON, SnapLED, etc.) and in the electronics, co ntrols a nd Solid State Lighting (SS L) modul e business (e.g. contro l s, LED m odul es, retrofits, special app lications, etc.). They apply these components and products in the foll owing "downstream" businesses; Consumer Lumina ires, Profess iona l Luminaires, Auto m otive Lighting and Special Lighting App lications.
Philips Lighting had a turnover of EUR 7, 1 billion in 200 8 with a total number of employees of approximately 53,000 (April 2009). Since the research proj ect will be executed at the business un it Contro ls in Eindhoven, 1 will from now on exclusivel y foc us on this business unit.
BUSINESS UNIT CONTROLS1
Global Business Unit (GBU) Control s, where this research is being executed, is one of the 4 GB U' s of the Bus iness Group Lighting Electronics and is responsib l e for providing products to give peopl e or compa nies the power to seaml essly manage and control their lightin g. The products range fro m 'simpt e' switch contro l s to complex integrated sys tems composed of user interfaces, sensors, co ntro llers, dr i vers, and system software. lncreasingl y, other systems, such as air-conditioning units, sec uri ty sys tems, or even Vidi wa lls, are also being integrated into lig ht ing co ntrol systems. T his develop ment is giv ing peopl e the cha nce not o nly to get a ll their light sources working together effectively, but also to m onitor and manage their critica ] resources more effectively. In short, lighting co ntro l s has th e potential to enhance the lighting, appearance, security, and energy efficiency of almost any home, offi ce or commercial bui lding. To su pport this Emerging market GBU Controls is div ided into three seg ments: Indoor Controls (S ta nd a l one & Networked Controlled), Outdoo r
1
(Philips-HRM, 2010)
Controls and E merge ncy Lighting. With locati ons
inEindhoven, Memphis, Manchester USA and Sydney th e GBU is providing products globally.
2.1.1
SOFTWARE DEVELOPMENTThe resource portfolio of BU controls
2consists out of 95 peo pl e, divided into 1 6 different roles.
Software engineering is by far the biggest competences pool within BU controls. Managing software proj ects and software resources effectively and efficient is therefore of utmost importance.
SOFTWARE ROLES
For software development projects four different roles can be identified; (1) the software project leader; (2) the software architect; (3) the software developer (SE); a nd (4) the software tes ter (ST).
The software project leader sets up a project team, plans and tracks project execution, and reports project progress to management. T he software architect defines the software architecture and coordinates software aspects in the team. Software developers and testers develop software as planned and report progress of activities to the software project leader.
In this research roles will be differentiat ed by experience level (i.e. junior or senior). T he differ ence between Senior a nd Junior is based upon the ex perience level. Seniors (i.e. more experi enced) produce genera! ly speaking more robust software with fewer errors. Juni or (i. e. less experi enced) empl oyees produce re latively spea king less robust software w it h more errors The differ entiation between senior and junior employees will on ly be appli ed on the engineering level, because only here, th is differentiation really makes sense in terms of productivity and error generation differences.
AGILE SOFTWARE DEVELOPMENT -SCRUM
Philips BU co ntrols adopted the so call ed SCRUM agile software development. SCRUM Agile developrnent is based on an iterative new product development cycle, where requirements and solutions evo lve through s mall self-orga nizing and cross-functional teams. "SCRUM concentrates on how the team members shou ld function in order to produce the system flexibly in a constantly changing environment" (Schwaber, 1995, p. 27). Flexibility is the key in this N PD process. T his paragraph briefly explains what SCRUM agil e development is for Philips BU controls.
When building a new product, a team gets different feature requests from users, customers, executives and eve n from people within the team (i.e. developers and testers). T he coll ection of a ll these features is called th e ' product backl og'. T his is a w is h list what wou ld make the new product great. Then th e tea m identifies t he featu res th ey want to put in the release. This results
inthe release backlog. On ly those features which really do matter are put in this backl og. After this is clone, th e team est imates how long it wi ll take for each featu re to be developed and tested. T his provides a rough idea of the total work invo lved to compl ete the release. Fro m the release backlog, s prints are being designed.
Sprints are short duration mile stones that allows people to tackle a manageable ' chunk" of the project, and get it to a 'ship ready' state. Within BU controls, the duration of each s print is set at 20 days. So the goal of every 20 working days is to get features out of th e product back log developed, fully tested, and ready fora 's hip ready state'.
2 Limited to resources of Resource Managers: Wiecher van Vught, Sander Klerk & Nico Ulder
The monitoring of each s print i s done by the so call ed ' burn-down chart' where the work remaining and the time rem a ining are pl ott ed on a piece of paper. Th i s provides a day by day measure of the amount of work that remains to complete a sprint. lt is easy to see from the burn down chart if the tea m is on track. Thi s i s perha ps the most valuabl e picce of knowledge that any tea m member, product owner, or executive can have about the project. Daily scrum meetings are organized to keep trac k of the progress, and what everyon e wi ll be doing ti ll the nex t daily scru m meetin g. Also pi tfa lls and other matters are being discussed in t his s hort meeting held daily. A s ummary of the SC RUM agil e process i s ill us trated in Figure 2.
Daily Scn..m
FIGURE 2- AN OVER VIEW
or
THE SCRUM METHODOLOGY2.1 .2
THE PROJECT STAFFING PROCESS24 Hours
Potent1ally ShJppable
PToduct
The resource all ocation process' aim i s to all ocate reso urces in such a way that project requests are satisfi ed a nd reso urces are allocated in an effi cient way (e.g. no hidden unempl oyment, no hidden overload). Today this is done by the ' resource allocati on sheet' whi ch supports the resourc e manager in allocating resources in an effi ci ent way. This Excel s heet shows the uti lization rate on a
pr~jectand the cum ulative util ization rate for eac h employee. This shows which employee i s over alloca ted and which empl oyee i s under-allocated at whic h m o m ent in time. The ' resource pipeline sheet' i s used as a planning too l which enables the reso urce manager to see how much FTE is needed of each ro le at wh ich moment in ti me. Thes e tools work exce ll ent as an overview and make it poss ib l e to cal cu l ate h o w much FTE and Euro is all ocated to each proj ect. However there are also seri ous drawbacks and limitations whi ch wi ll be sho wn in the next paragraph.
2.2 PROBLEM ARTICULATION
The most importa nt limitations of the resource a llocati on tool s is that the too l s are statie, and do not incorporate feedbac k mechan ism. For exampl e; when a project wilt be under all ocated, beca use of a resource co nstraint i ssues, a project wil l probably be delayed, which res ults in the utilization of so me resources fora longer tim e. These efTects are not inc luded in these meth ods. Al so, a llocating too few resources toa project with a fi xed dead line i s like l y to ca use shortcut taking whic h decrease qua lity.
Al so these effects are not included in the current mode l s of BU controls.
So, li nking project staffin g decisions with project performance is like l y to benefit the resource
all ocati o n process, since all ocation decisions can be based on proj ect perfo rma nce characteristi cs in
terms of costs quality and duration. T his is a first vital step towards a hi gh quality aggregate multi- project. It will g ive interesting insights in how differe nt all ocatio n strategies affect overall pro j ect performance. Besides t he th eoretica! r elevance, as being discussed in the previous cha pter, BU controls will also benefits from enhanc ing its knowl edge co ncern ing the effect s of project staffin g on project duration, quality, and costs.
This leads to the following Research Question;
Research Question
What are the effects of different project staffing decisions on project performance, in terms of costs, duration, and quality in an Agile Software Development project?
lt w ill c lear up the research question if ' different proj ect staffing decisions' and ' project performance' will be defi ned. First, project s taffing decisions will influence the outcome in two ways:
1. T he s ize of the project team will influence the outcome o f the project. For example, large project teams are ab le to fini sh a project faster, compared to a small project team.
2. The sen ior / junior ratio also affect proj ect performance by means of quality, and by other interaction effects (e.g. Junior's need time from seniors to keep on workin g, w hi ch decreases seni or productivity)
3. Fluctuations in teams will also influence the outcome of a team. Adding people nea r a deadline of a project will likely not be very benefic ia! toa project outcome.
T h en, the performance of the project is defined by three performance indicators;
1. Project Costs; whi ch is the cumulative costs of different huma n resources (d ifferentiated by roles and se niority)
2. Duration of the project; which is the time from start to finish, whe n all pl anned tasks are don e.
3. Quality, whi ch is derived from the percentage of undet ected errors remaining at the end of a proj ect, (see a lso Austin (2001 ))
2.3 RESEARCH DESIGN
In this section, th e approac h to a nswer the research question w ill be presented. According Dav is et a l (2007) is s imulation the favo red approach when the research question involves a tension or trade-off among oppos ing factors. Different approaches can be used to ans wer thi s research qu estion. Wang (2005) deco mposed the Operat ional Research (OR) work.force planning methods into tour major categori es: Markov C hain Models, Statie Si mulation Models, Optimization Models, and System Dynamics Models . T he firs t three methods discussed, share a common drawback. T hey are linear in character and are not able to capture the dynamics of a project.
System Dynamics, however, is capable of address ing dynamics a nd non-linear complex systems. lts
strengths lay in the holistic approach in investigation the complex dynamic behavior of systems
(Reichelt & Lyneis, 1999; Rodrigues & Bowers, 1996 ; Wang, 2005). System dynamics i s also able to explain the dynam i c behavior of opera tional processes. The m odel s of Forrester and Wright ( 196 1) for example, these are sci entific theoretica! m odel s of operati onal processes, wh i ch exp l ain and pred i ct the dy na mic behav i or and performance of processes. Thereby these mode l s ca n be validated empiricall y (Bertrand & Fransoo, 2002) which can br idge the ga p between rigor and relevance.
Besides its descriptive power, rece nt computer simulation software developers incorporated optim ization algorithms, which allows calcu l ating optima! so lutions of a complex system. Rodrigues and Bowers (1996) al so stress the concern to co n s i der the whole project rather than a sum of indi vidual e l ements (the ho listic approach); and the need for a flexibl e proj ect model which offers a laboratory for experiments with management options. For these reasons, the System Dynamics meth od is chose n.
SVSTEM OYNAMIC MODELING PROCESS
There is no best practice for a system dynamic modeling process, yet a ll successfu l modelers fo ll ow several steps (Sterman, 2000). Maani and Cavana (2000) developed a model ing process consi st ing of 5 steps wh i ch gives the mode l er insights in which phases and steps it should address. These phases corre s pond very much with the model ing process of Sterman (2000). The process of Maani a nd Cavana will be presented. This process also represents the structure of this thesi s. The chapters of the correspondi ng steps are put between brackets after every steps na me.
1. Problem structuring (chapter 1-2.3): In this step the boundaries of the system of the system needs to be identified, and primary data needs to be co llected to identify the proble m.
2. Dynamic hypothesis / Causa/ loop diagra mming (chapter 3): in the seco nd step, the main variables need to be identified, and the relati on ship across variables needs to be identified, and i llustrated with a causal loop diagram. This process i s often skipped but will enhance the conceptual rigor and learning power of the system s approach (Maani & Cavana, 2000;
Sterman, 2000)
3. Dynamic modeling (chapter 4): in this phase, the conceptual model from step 2 needs to be transferred to a quant i tative stock-flow diagram. Then, deta iled historica! proj ect data will be coll ected (e.g. proj ect progress, amou nt of rework & resourc e level s). lf the model i s fini shed and the data i s collected, th e conceptual model can be compared to rea l time historica ! data. This sho ws ho w able the model i s to reproduce the project behavior over time, w hich proves internal validity ( Davi s, Eisenhardt, & Bingha m , 2007). Finally, various tests will be executed to build co nfidence in th e mode l
4. Scenario planning and modeling (chapter 5): D evel op and s imu l ate alternative scenarios, evaluate rob ustness, co mpare res ults. In this phase, severa l di fferent (real life) scenarios are postu lated and tested. The scenarios will be imp lemented in the model and model output will be compared to the rea l -project behavior from projects whic h encountered the s pecific scenarios. Finally, a robustness test will be executed.
5. Implementation & evaluation (chapter 6): Report and present resu lts to stakeholders,
deve l op a ' managem ent tlight simu l ator' to faci litate learn ing in the organization).
2.4 DEMARCATION
Human resource c haracteristics: Although human resources can be generali zed in roles, se niori ty and type of contract, there w ill still be di fferences in other characterist ics (e.g. type of team player, personality). In real life idea l teams are carefull y compos ited, and d iffe rent perso naliti es are taken into account. T he mix of persona lit ies and the mix of co mpet ences also affect project performance. T hese factors of huma n resources w ill not be taken into account. Only differences qua ntity, seniority, and ty pe o f roles wi ll be take n into account.
Also effects li ke work pressure w ill have diffe rent effects o n different type peo pl e. T hese prec ise differences will not be taken into account, instead a ge neralizat ion will be made, a nd these effects wi l!
be averaged.
Software deve lopment: The mode l will be developed for a software deve lopment project. Also rea l historica! data from a software deve lopment proj ect w ill be co ll ected. Hardware or Mecha nica!
proj ects are beyond the scope of this research.
Roles: In software deve lopment proj ects 4 different roles are most important. T his research will espec ially foc us on the proj ect operations, w hich involves especiall y the sof tware engineers and software t esters. T he software proj ect leader and software architect, who a re mostly supporting th e project, w ill not be t aken into accou nt in this research.
2.5 SUMMARY AND OUTLINE
T he main research deliverable can be summari zed as fo llows. The ma in obj ective of thi s research is to prov ide insights into the consequences of different project staffi ng dec isions. A syst em dynamic model will be deve loped, which ca lculates the effects of di fferent project staffing decisions on the proj ect duration, the proj ect quality, a nd the proj ect costs. Historica! and survey data will be used to prove internal validity.
The thes is is organi zed as follows. C hapter 3 presents the dynamic hypoth es is and explains the relations hips across varia bles. Next, chapter 4 tra nsforms the co nceptual model into a quantitative model. T his cha pter w ill discuss th e mathematica( foundation of the model. After that, chapter 5 wil]
execute, ana lyze, a nd disc uss d ifferent proj ect staffing scenarios. T hen c hapter 6 applies th e model in pract ice. Finally, cha pter 7 will present the conclus ion a nd reco mmendations of this research.
Dynamic Dynamic Scenario Applying the Conclusion and
hypothesis ~ modeling
•
analyses•
model•
recommendations(chapter 3) (chapter 4) (chapter 5) {chapter 6) (chapter 7)
3 DYNAMIC HYPOTHESIS
This c hapter wi ll present the dyna mic hypothes i s and is structur ed as fo ll ow. First, it wi ll discuss the identification process of proj ect dynamics within Philips BU controls. This will make clear which dynam ic behaviors are at stake in the various projects. The second secti on builds on that knowledge and s hows the res ult of the identiticati on process with support from both theo ry a nd practice. This section careful ly il lustrates how variables are rel ated to each other and wi 11 explain the different dynamic behaviors in the form of a Causal Loop Diagra m (CL D)
3.1.1
IDENTIFICATION PROCESS OF THE DYNAMICS WITHINBU
CONTROLSIn literat ure and practice var i ous dynamic behaviors have been identitied
111projects. The most co mplete s ummary of these dynamic behaviors i s th e one of Lyne i s and Ford (2007). Their CLD summarizes man y of th e bas i c dy namic behavior within so ftware developm ent project s. For this reason, this framework has been used as a bas i s for th e identification of dynamic behav i ors within Philips BU Contro l s. Besides this framework, the Human Resource Management subsystem of Abdel- Hamid ( 1989) has also been used as a basis for the project staffing dyna mics s i nee thi s dynam ic model foc uses more on proj ect stafting.
To a n s wer the questio n, which dynamic behaviors are important for BU controls, se mi-structured interviews have been executed with various projec t ma nagers across the BU. A limited set of questi on has been as ked to m anagers to explore the dynamic behav i ors within co ntrols. lnterviewees wher e asked how far the dynamic behavior i s applicabl e for BU co ntrols projects. Also interviewees had the opportunity to add dynamic behaviors to the fram ework if needed. If m ore tha n th ree intervi ewees recognized the theoretica! behavior it has been included in the CLD which wil l be discussed in the next paragraph.
The results showed that apart from " Hopefu ln ess" all dynamic rel ationships are applicable to projects within BU controls. Hopefulness i s described by Lyneis and Ford (2007) as a decrease of the morale due to too much rework. Most of the interviewees did not believe this does innuence the m ora l e of the employees. One interviewee even mentioned that Phili ps has the lot of knowledge to tackl e va rious d ifficult prob l e m s, and that a lmost a ll techni cal chall enges are be solved by the eng ineers. So this rein forces the state m ent that hopefu lness hardl y occ urs since engineers are hardly are at their wits ' end.
Besides the dynamic behaviors which are described by Ly nei s a nd Ford (2007) and Abdel -Ha mid (1989) the interviewees revea led some e ther im portant rel ationshi ps. Thi s i s not surprising l y, s ince this resea rch espec iall y focuses on proj ect staffin g and project performanc e interdepe ndencies. In tota l four extra relati o n s hips have bee n dis covered. An introducti on into these extra relations hi ps will be disc u ssed here, a nd m ore detai l s how these variables relate to others can be fo und in the next sectio n where the CLD is being discuss ed.
(l) Senior and .Junior iriflu ences on the project; in general pro ject ma n agers state that the right
mi x of juniors and seni ors i s needed. For co mpl ex projects, more seniors are needed as fo r
s imp Ier projects. Other al s o stated that juniors work on s maller aspects of a project, and nee d
time from senior to keep on th em on track. All interviewees stated that the diff erence between juniors and sen iors s hou ld be taken into acco unt.
(2) The ejfects of a reconstitution; at the end of year 2009 a reconstitution has changed the resource portfolio of Philips BU contro ls. So me project teams have been affected by that.
lnterviewees mentioned that due to the reconstitution, some teams decreased in s ize, whi ch delayed the project drastically. Besides a delay, the morale of so me employees also decreased, s ince people were not motivated to put effort into the project because they have to leave the company anyway. A reconstitution is a decision which is taken by top management taken outs ide project related issues. It thus can be cons idered as an exogenous effect.
Therefore, this effect wil 1 not be taken into account in the dy namic model which will be developed in chapter four.
(3) The .fresh view effect on a project; when people are added to a proj ect, three things wil 1 happen. They need time to become productive, and to become productive they utilize time from other team members, which is a lso disc ussed by Abdel-Hamid (1989). However, interviewees a lso stated that w hen new people are introduced, errors will be detected earlier due to a fresh view on the project.
( 4) The ejfects of software testers; if more testers are added t o a project, errors can be detected faster. However, more testers will not necessarily increase the quality of the project. Also here the right balance is needed, e ngineers and testers needs to be balanced as well.
Besides these four extra dy namic behavi ors, 12 other relationships have been recognized by th e interv iewees. The next section will discuss all 16 relationships and puts them in a customized C LD.
Also the o pinion of the interviewees is included in the next section if applicable. For the original C LD from Lyn eis and Ford (2007) 1 refer to Appendix 9. 1 .
3.2
CUSTOMIZED CAUSAL LOOP DIAGRAMThis section will vis ualize the dynamics within projects in the form of a customized C LD. A CLD gives a broad representat ion of the feedback structure of a project. A CLD consis ts of variables connected by arrows denoted by a link polarity. The arrows bet ween varia bles represent a causa ( relations hip, while the link polarity s hows if this is a negative or positive relationship. Loop polariti es, indicated as a '+' or '-' with an arrow around it refer to a reinforc ing or balancing loop respectively.
A reinforcing loop is one in which the interactions of the variables adds to the other and thus re i nforce eac h other. A balancing loop is a loop w hich attempts to brin g two things to agreement.
A CLD's advantage is its limited use of symbol s and its focu s on the loop structure, which makes it
understandabl e for non-technica! people. T herefore, this tool is convenient in communicating a mode l
and is of great help in connecting s imulated behavior back to its structural source (La ne, 2000). A
drawback of C LD's however, is that they do not always expl ain we ll how flows influence stocks,
which may lead to mis-labeling of loop polarities (Richardson, 1986). Also Sterman (2000, pp. 210-
2 11 ) acknowledged t his problem and advised to include a stock and flow structure when phys ical
processes, delays or stocks whos e behavior is important, are involved. Because according to the
conventions a CLD only inc ludes variables w hich are connected with arrows, I will develop a
customized C LD, which includes some basic stocks and flows as well. Because this creat es better
insights in how s tocks and tlows are be ing intl uenced. Consequently 1 will extend the bas ic rework cyc l e whi ch consi sts out of stocks and fl ows (SF O) with variables a nd arrows in fo rm of a CLD.
The next sectio n will first di scuss th e rework cycle and the relations hips among di fferent variables.
Step by step, more variables are being inc luded and the causa l relationships will be expl ained a nd illus trated, unt il a ll dynamic behav i ors wit hin the BU co ntro ls projects are being describ ed and illustrated.
3.2.1
THE REWORK CYCLE(1/3)
The rework cyc le is, acco rding Lynei s a nd Ford (2007), th e most im po rta nt s ingle feature of sys tem dynamic project m odels. It s hows the Wor k in Progress in a development process. lt disc riminates betwee n tasks being correct and tasks needing rework. This allows fo r example th e modeling of ' Er ror buil ds Erro rs' (Ly nei s & Ford, 200 7; Reichelt & Lynei s, 1999), which means that rework ge nerates more rewo rk. Rework cyc les can di ffer in s tructure and are dependent on the type of a specific deve l opment process . In genera( two types of rewor k cyc l es a re mostly used; the one of Coo per ( 1993) and the one of Fo rd a nd Sterma n ( 1 998). Both incorporate at least 3 similar stocks: Original
W ork to Do, Rework to Do and W ark Done.
F!GURE 3 • A CUSTOMIZED REWORK CYCLE
Productivity
+
<leve lopmcnt ra te
~
Process Quatity
e ffort
Work Done
rework rale
Regarding the cont ext 1 a dopted the rework cycle of Cooper ( 1993) with so me minor changes to
incorporate agil e development (see Figure 3). My rework cycle co nsists out of 6 stocks; ( 1 ) work to
do total, which contains all the work from all th e projects; (2) work to do jor project, which contains
the work fr om one project; (3) work to do for sprint, which contains only the work whic h wi ll be
executed in a part icular sprint; (4) undiscovered rework, which conta ins the undiscovered rework fora
pa rticul ar pro ject; (5) rework to do , which co nt ai ns the rework to do fo r a particular pro j ect; and (6)
work done per project, which contains all work which i s do ne duri ng a parti cula r pro j ect. The
development rate represents the rate of work what is being done correctl y. And the error genera/ion
rate represents the work whi ch is done ' inco rrectly' and needs rewor k. These two rates are
deter mined by 3 important variables; ( l ) effort whi ch consists ou t of the team members in FTE; (2)
productivity which determines the efficiency of the team members working on the project; and (3) th e
quality of the work. Since th ese variables are importa nt variables, they will be furth er expla ined in
the next chapter where the dyna mic model is being introduced.
3.2.2
PLANNING AND CONTROL(2/3)
To plan a proj ect, inf ormat ion whether work can be ti nished in t ime needs to be ava ilable. T he following extens ion shows that if the work to do for sprint is large, the per s on-days work remaining is also large. lf this va lue is co mpared to the allocated resourcesfor the project then the days required can be calcul ated and the perceived schedule slippage can also be det ermined.
\\\.Il~ ( " ,J,) l\1t:.li
(
+ +
~it.: .ckip ~r• r.lh:
~---t.'!"~'Tl
h.'\\\\n.:
~fl-..nhl'I\
pcrcci,1!d project
\
allocaied resources tor
/ ' "'
(
slippagi:
~Deadli
person-days + days required
+
workrerrairin~
FIGURE 4 - CLD; THE PROJECT BASIS
The a im of the proj ect is t o develop all th e work before the deadline is being passed. T herefore, there
are 5 contro l mec hanism w hich are used within Philips BU controls; ( 1) SE engineers automatically
change ( i.e. increas e or d ecrease) th eir work intens ity, dependent on th e perceived s lippage whic h
positi vely influences productivity; (2) more proj ect s lippage can result in working overtime, whi ch
w ill be used to achieve the deadline; (3) people ca n be added to th e project team to increase effor t; (4)
deadlines can be postponed which results in a decr ease of s lippage; a nd (5) functiona liti es can be
deleted or add ed whi ch can provide the t imely fi nish of a proj ect. All these re lations hi ps are illustrated
in F igure 5.
CJ • :&
scope dccrcasc
FIGURE 5- CLD: PROJECT CONTROL
+
"
,
+fiaclion of software Testers
. U
~f
X'lll!'l\'{l,'\e,
+f
won. iltensityadd people
overrime
