The dynamics of software project staffing: a system dynamics based simulation approach

The Dynamics of Software Project Staffing: A System Dynamics Based

Simulation ApproachTarek. K. Abdel-hamid

IEEE Transactions on Software Engineering (1989)

Seul-Ki Lee2009. 07. 21

Contents

IntroductionBackgroundComposition of subsystemHuman resource management subsystemCase studyConclusionDiscussion

ⓒKAIST SE LAB 2009 2/21

Introduction

Software project staffing is very importantDue to lack of human resource management

• Causing cost overruns, late deliveries, poor reliability, dissatisfaction of users

Need of the fundamental understanding relationship for human resource process between cause and effect

In this paperSuggest the system dynamics model for project managementCheck staffing principle by using system dynamics model


Background(1/2)

System dynamicsDefinition

• An approach to understanding the behavior of complex systems with time

Characteristic• Information feedback systems with feedback loop

– Positive loop (reinforcing loop) : even number of negative flow– Negative loop (balancing loop) : odd number of negative flow


Background(2/2)

Expression of system dynamics Level – an accumulation or integration of informationRate – a increasing or decreasing amount of flowParameter – a factor for deciding the level or rateFlow – a stream of information in the system

Source Sinklevel

auxiliary

rate rate

constant

Influencing variable

Valve of the flow increasing or decreasing a level

Container for flow accumulating

Other flows (e.g., People, Software)

Information flows value of algebraic computation

Composition of subsystem

System dynamics model developed by authorCreation of the integrative model for single projectConstitution of four subsystem

• Focus on human resource management subsystem due to the purpose of this paper

6/21ⓒKAIST SE LAB 2009

Human resource

management

Softwareproduction

Controlling Planning

Progressstatus

Taskscompleted

Work forceavailable Work force

needed

Schedule

Effortremaining

Human resource subsystem (1/3)

Overall system

“level” var.“rate” var.“auxiliary” var.constant valueinfluencing var.

Hiring Rate

Workforce Assimilation

Rate

Quit rate(Turnover)Newly hired

Transfer rateExperienced Transfer rate

Hiring Delay

Average Assimilation

Delay

TransferDelay

Most new hires per

FT Exp Staff

Average Employment

Time

Transfer Delay

Newly hired Workforce

Experienced Workforce

Total workforce

Workforce Gap

WF level sought

Ceiling on total

workforce

FTE Experienced Workforce

Ceiling on new hires

Workforcelevel needed

7/21


Main flowDifference in productivityBoth technical and social training overhead

Average time for taking a new recruit to be trained

Adjust the number of peopleto be experienced workforce


Hiring Rate


Rate

Quit rate(Turnover)

Hiring Delay


Delay Average Employment

Time



Newly hired Transfer rate

Experienced Transfer rate

TransferDelay

Transfer Delay


Overall system

“level” var.“rate” var.“auxiliary” var.constant valueinfluencing var.

Hiring Rate


Rate

Quit rate(Turnover)Newly hired

Transfer rateExperienced Transfer rate

Hiring Delay


Delay

TransferDelay

Most new hires per

FT Exp Staff

Average Employment

Time

Transfer Delay



Total workforce

Workforce Gap

WF level sought

Ceiling on total

workforce


Ceiling on new hires

Workforcelevel needed

9/21

1

2 3

1. Decision of workforce level sought

Limitation in the workforce level soughtSet the maximum number of new staffs

• To control the new hired staffs by each experienced staff well

Ceiling on New Hirees= (Full-time equivalent experienced workforce)* (Most New Hires per Full-time experienced staff)

Most new hires per

FT Exp Staff


WF level sought

Ceiling on total

workforce


Ceiling on new hirees


FTE: full-time equivalentWF: workforce

2. Feedback loop on the workforce

Select the activity of workforce gap Difference between “Workforce Level Sought” and current “Total Workforce”

• ① = ② , no further staffing actions would be necessary• ① > ② , new staff will be added to the project• ① < ② , project members will be transferred out of the project

ⓒKAIST SE LAB 2009

Hiring Rate

Workforce Assimilation Rate

Newly hired Transfer rate

Experienced Transfer rate

Hiring Delay

Average Assimilation Delay

TransferDelay

Transfer Delay



Total workforce

Workforce Gap

WF level sought

Ceiling on total

workforce

Workforcelevel needed1

2

111

222

Compare indicated workforce with total workforceIndicated workforce

• Suggested workforce for the remaining time in current

Current total workforce• Current workforce that is sum of newly hired and experienced

workforce

Calculate workforce level needed

3. Workforce level needed

= (Indicated workforce) * WCWF + (Current total workforce) * (1-WCWF)

Indicated workforce> Total workforce

= (Indicated workforce)

No Yes

WCWF=Maximum(WCWF-1,WCWF-2)

WCWF : Willingness to Change Workforce

Willingness to change workforce (1/2)

Expression of a policy for managing projectsWCWF-1 (workforce stability)

• Manage the number of new hirees toward end of the project• Use time parameter consists of hiring delay and average

assimilation delay• As time goes by, WCWF-1 value is approaching zero

1.0

0.80.60.40.20

0.3 0.5 0.9 1.2 1.5

WCWF value

WCWF-1

(Time Remaining)(Hiring Delay + Av. Assimilation Delay)(Time Parameter) =

Stop to add people

Start becoming reluctant to hire new people


Willingness to change workforce (2/2)

Expression of a policy for managing projectsWCWF-2 (schedule stability)

• Manage the schedule completion time toward end of the project• As time goes by, WCWF-2 value is approaching one


WCWF-21.00.80.60.4

0.20

0.7 0.8 0.9 1.0

(Scheduled Completion Date)

(Maximum Tolerable Completion Date)

WCWF value

For keeping the schedule

Case study (1/4)

Experiment backgroundDE-A project

• Conducted at the NASA for DE-A satellite• Process telemetry data, provide attitude determination and

control for DE-A satellite• Serious slippages could not be tolerated

Purpose of this experiment• Check the probability of human resource management by using

model• Check the human resource management principle that is

Brooks’ Law

Assumption of Brooks’ Law• Adding manpower to a late software project makes it later


Case study (2/4)

Model experimentationResult of simulating the behavior of the DE-A project

• Estimated data is following actual data well by using feedback loop

(1) Scheduled completion date (days)

(2) Estimated project cost in man-days

(3) Workforce (people)

(1)

300

200

100

0.0

400

2250

1500

750

0.0

3000

11.2

57.

53.

750.

015

.0

(2) (3)

Design Coding Test0. 100. 200. 300. 380.

TIME (Days)

DE-A’s actual “Scheduled completion date” (days)DE-A’s actual “Estimated project cost in man-days”DE-A’s actual “Workforce” (Full-time equivalent people)

16/21

Case study (3/4)Brooks’ Law to the DE-A project

Reformulating the WCWF to be solely a function of WCWF-1 for Brooks’ Law

• Brooks’ Law can not apply to the this project– Approximately three calendar months more than what was

required in the base case

15.

11.25

7.5

3.75

0. 0. 100. 200. 300. 380.

TIME (Days)

Workforce(People)

Design Coding Test

15.

11.25

7.5

3.75

0.0. 100. 200. 300. 400.

TIME (Days)

Workforce(People)

Allow adding new staffs(avoid the Brooks’ Law)

Prohibit adding new staffs(follow the Brooks’ Law)

440.

Case study (4/4)Brooks’ Law to the DE-A project (cont’d)

Test for a wide range of manpower policies• Keeping same workforce level• Brooks’ Law only holds when the time parameter is less than or

equal to 30 working days

Project cost (man-days)

Project completion time (Working days) 450

400

350

0

2,500

2,000

1,500

Completion Time

Project Cost

Time parameter20 40 60 80 100

In Brooks’ Law,Smaller project cost makes shorter completion timebecause time parameter makes to stop adding staff

Conclusion

ConclusionCreation of system dynamics model for managing project development

• Easy to understand the system behavior by using feedback loop for handling complexity

Suggestion of counter-example of Brooks’ Law• Brooks’ Law does not apply to the project always

Future workModel enhancement

• Consideration of multiple projects in parallel• Investigation about large-scale project environments


Discussion

ContributionCreation of system dynamics model

• Capture information from observation and experiences

Validation of Brooks’ Law

LimitationLack of the number of case study


Thank you

Software production subsystem

Overview (four primary activities)Development, quality assurance, rework, and testing

“level” var.“rate” var.influencing var.

Software Development Rate

Software Developed

Software Development Productivity

Software Testing Rate

Software Testing Productivity

Man power


Scheduled Completion Date

Rate of adjustingschedule

Planning subsystemOverview

Initial project estimates are made, those estimates are revised throughout the projects life cycle

Workforce Level Needed

Indicated Completion Date

Workforce Level

Sought

WCWF

WCWF-1

WCWF-2

Indicated Workforce Level

Time Perceived Still

Remaining

Time Remaining

Average Daily Manpower per Staff

Time

Man-days Remaining

Ceiling on Total

WorkforceTotal

Workforce

Maximum Tolerable Completion Date

Average Assimilation Delay

Hiring Delay

23/21

Willingness to change workforce

Flow of the value by timeWCWF = Maximum (WCWF-1, WCWF-2)

24/21ⓒKAIST SE LAB 2009

Time

Value of factor

WCWF-1

WCWF-2

WCWF

The dynamics of software project staffing: a system dynamics based simulation approach

Documents