The Impact of Staff Turnover on Software Projects:

The Importance of Understanding What

Makes Software Practitioners Tick
Tracy Hall Sarah Beecham June Verner David Wilson
Brunel University University of National ICT Australia University of
London, Hertfordshire Sydney, Technology, Sydney
United Kingdom Hatfield, Australia Sydney,
tracy.hall@brunel.ac.uk United Kingdom june.verner@nicta.com.au Australia
s.beecham@herts.ac.uk davidw@it.uts.edu.au

ABSTRACT
In this paper we investigate the impact of staff turnover on
software projects. In particular we investigate whether high staff
turnover damages project success. We analyse data from an
empirical study of 89 software practitioners to show that projects
with high staff turnover are less successful. Furthermore our
empirical data suggests a relationship between high staff turnover
on projects and low staff motivation levels. We discuss factors
which have been previously found to improve motivation levels
and conclude that improving motivation levels can reduce staff
turnover, which in turn increases project success.
Categories and Subject Descriptors
D.2.9 [Software Engineering]: Management productivity,
programming teams
General Terms
Management, Performance, Human Factors.
Keywords
Motivation, project success, staff turnover.
1. INTRODUCTION
Employment in the information supersector is
expected to increase by 11.6 percent, adding
364,000 jobs by 2014. Information contains
some of the fast-growing computer-related
industries such as software publishers; Internet
publishing and broadcasting; and Internet
service providers, Web search portals, and
data processing services. Employment in these
industries is expected to grow by 67.6 percent,
43.5 percent, and 27.8 percent, respectively.
US Bureau of Labor Statistics (2006)
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SIGMIS-CPR08, April 35, 2008, Charlottesville, Virginia, USA.
Copyright 2008 ACM 978-1-60558-069-2/08/04...$5.00.
The above quote implies that reducing staff turnover will become
increasingly important for software companies. The US
Department of Labor predicts an expansion of the information
sector such that companies are likely to struggle to recruit
sufficient staff. For that reason alone retaining existing staff will
become critical to companies. However staff turnover may also
have a more direct impact on projects. We investigate the
particular impact of staff turnover on the success of individual
projects.
Software has been developed since the 1960s but still little is
known about how to ensure that software projects are successful.
The Standish Group reports that 35% of software projects
commenced in 2006 are successful [33] compared with only
16.2% in the corresponding 1994 report; however, the 6th
CHAOS report still identifies 46% (52.7% in 1994) of software
projects as challenged (having cost or time overruns or not fully
meeting users requirements) and 19% (31.1% in 1994) as
outright failures [33]. Despite the obvious improvement, 65% of
software projects being unsuccessful is still unacceptably high.
Glass [14] called these runaway projects when he discussed 16
project disasters in 1998. Recently Charette [9] suggests that
billions of dollars are wasted each year on failed software
projects and that we have a dismal history of projects that have
gone awry, while other studies as recent as 2006 suggest various
failure rates for software development projects up to 85% [17].
[9] provides a long list of high profile failed projects from around
the world in his Hall of Shame and suggests that 5%-15% of
projects will be abandoned before or shortly after delivery as
hopelessly inadequate. Other widely publicised disasters include
the temporary collapse of the Tokyo stock exchange [18], the
power outage in north-east USA [26], and the Therac-25 radiation
therapy machine [10]. Software failure stories capture public
attention because of the financial, technological and social
dimensions of systems today [5] and in general there is a
perception that software quality is not improving but getting
worse [7]. Developing software systems is an expensive, and
often a difficult process as software development projects are
affected by a series of problems, such as poor project
management, cost and schedule overruns, poor quality software
and under-motivated developers [4;8]. Although there are many
guidelines for successful software development (e.g., [24; 32],
few project post-mortems are conducted, and little understanding
is gained from the results of past projects within organizations.

30
In this paper we investigate the impact of staff retention on
project success. Retention of staff is an important issue for
organisations as the costs of high turnover can be substantial. In
addition to the direct costs of recruiting a replacement, there are
indirect costs associated with the loss of key skills, knowledge
and experience [16]. Latimer [20] identified three phases of the
staff turnover process, all of which contribute to the cost of
turnover:
Separation costs associated with lost or decreased
productivity and disruption to operations as an incumbent
leaves, with the position being possibly vacant for a period
and displaced work falling on others;
Acquisition costs associated with advertising, interviewing,
selecting and employing a replacement; and
Knowledge transfer and training costs associated with lost
institutional knowledge, the learning curve of the replacement
and on-the-job training of replacements.
Across these phases, as this is a disruptive and time-consuming
management process, there are also additional costs in
management time and energy. All of these issues may have
important impacts on the success of software projects.
Job satisfaction [2; 29], motivation and de-motivation [12; 23; 28]
are reported as predictors of staff turnover. Software developers
are likely to stay longer in the job if they are satisfied [2] whereas
even organizations that offer competitive salaries and work with
leading-edge technologies experience high levels of
dissatisfaction and higher than desired turnover among their IT
staff [2]. Furthermore our previous work has also found that
project success is more directly linked to motivation
practitioners consider software projects successful if they provide
intrinsic, internally motivating work to develop software systems
that both meet customer/user needs and are easy to use [31]. One
particular motivator, salary, has been found to have a major
influence on staff turnover. For example, Garden [13] found that
salary is the single most important reason for wanting to leave.
Dittrich et al [11] also suggest that equity in rules used to give
pay raises is by far the most significant predictor of intentions to
quit. However overall, job satisfaction has been found to be a
steadying influence on turnover intentions [21].
We present empirical data collected from 89 software
practitioners from a variety of US companies. The data was
collected using a questionnaire which was developed as a result of
a literature review (see Appendix 1). The data we present shows
developers perceptions of factors impacting on project success.
In this paper we pose the following research questions:
RQ1: Is staff turnover related to project success?
RQ2: Are motivation levels related to staff turnover?
RQ3: What factors impact on motivation?
In answering these questions we present information useful to
project managers on the direct impact of motivating software
practitioners. We also present factors that managers can focus on
to improve and maintain staff motivation, reduce turnover and
ultimately improve project success.
In the next section of the paper we describe our data collection
and analysis. In section three we present our empirical data on
project success, staff turnover and staff motivation levels. In
31
section four we analyse the literature to present the state-of-the-
art factors that affect motivation levels. We discuss the
implications of our results for industry and our conclusions for
future research in section five.
2. METHODOLOGY
We conducted structured discussions with 21 senior software
practitioners who were employed by a large U.S financial
institution that developed software for its own use (Group 1).
These discussions covered a number of important software
development topics specifically focusing on a development
project with which each respondent had recently been associated.
Based on these discussions, and on an extensive review of the
literature, we developed a questionnaire (an excerpt of which is
shown in Appendix 1) to address major software project success
factors in seven broad categories, namely:
(1) requirements,
(2) management,
(3) customers and users,
(4) estimation, schedule, and staffing,
(5) the project manager,
(6) the software development process,
(7) development personnel.
We investigated the current state-of-the-practice of software
development with practitioners from Group 1. These practitioners
were based in a number of different U.S. locations and they
reported on 42 different projects. We followed this initial study
with another two studies that questioned developers from a
variety of organizations in order to investigate if the results from
the first case study were generalizable. Our second study (Group
2), targeted a group of software practitioners from a number of
different business organizations (i.e., insurance, financial,
pharmaceutical, and local utilities) in the United States involving
70 projects; nearly all these projects were developed for in-house
use, i.e., not developed for a third party. The third study (Group
3), with 41 projects involved a group of software developers from
Sydney, Australia, who were also mainly developing in-house
software for commercial organizations (i.e., insurance, financial,
telecommunications etc.). All three developer groups completed
our questionnaire. Our sampling of practitioners was not random,
but rather a convenience sample of developers to whom we had
access; all respondents participated in various project
management courses taught by the authors.
3. EMPIRICAL RESULTS
3.1 Project Success
Figure 1 (all figures are located in Appendix 2) shows that overall
the majority of projects in this survey are considered by
companies to be a success, with only 20% of projects not
considered successful. This is in contrast to the data reported in
the literature where project success is said to be much lower. We
also collected data on whether the software practitioners
themselves thought these projects where successful and slightly
more projects were considered to be successful by the
practitioners themselves than by the companies. However our data
suggests a healthy base set of projects in this sample.
3.2 Staff Retention
Figure 2 shows a variable relationship between project success
and staff turnover. However there are no statistically significant
relationships between project success and staff turnover. This may
indicate that some successful projects may manage turnover while
unsuccessful projects have more difficulty coping with turnover.
On the other hand this may be a reflection of more successful
projects experiencing lower turnover than less successful projects.
Another interpretation of this inconclusive result could be that
less successful projects have deadwood developers who have
been with the project or company for a long time but do not
contribute significantly to project success. However the weak
relationship shown may simply be a reflection of the data being
spread too thinly across the turnover categories. Whatever the
reason for this result the relationship between project success and
turnover needs further investigation.
Figure 3 suggests a stronger relationship between staff turnover
and motivation levels. There is a positive relationship between
lower staff turnover and higher motivation with no serious staff
turnover for developers reporting very high motivation.
Furthermore a Pearsons correlation test shows a significant
relationship between turnover and motivation at the 0.01 level.
This result strongly suggests that staff who stay in their job are
likely to be motivated. This could be an important benefit to
companies which retain staff.
3.3 Motivation Levels
Figure 4 shows a fairly positive range of motivation levels in the
projects reported by the 89 respondents. The vast majority of team
members on the projects have average or above motivation levels.
Further analysis of this data suggests no particular difference in
motivation levels between maintenance and development staff.
This is contrary to popular belief which suggests that maintenance
staff are generally less motivated Ed Yourdon is quoted as
saying maintaining a computer program is one of lifes dreariest
jobs for most American programmers it is a fate worse than
death [34, p12] and recent reports indicate that software
maintenance issues are much the same as they were in the 1970s
[25].
3.4 Motivating Factors
Figure 5 shows the relationship between motivation levels and the
project itself. In this data set we found no statistically significant
relationship between the project and motivation. The literature
suggests that the project itself is usually a strong motivator so this
is a surprising result (see separate list of references for software
development motivation at the end of the paper).
Figure 6 shows the relationship between motivation levels and the
project manager. The relationship between project managers and
motivation is significant at the 0.05 level using a Pearsons
correlation test. The motivational impact of the project manager is
encouraging, as this confirms that motivation levels can be
influenced by good project management.
However both the project itself and the project manager appear to
have limited influence on very highly motivated team members.
Figure 7 suggests a relationship between motivation and control
in staff selection - there is a steady increase in motivation when
team members are consulted in relation to staff selection.
32
However this is not a statistically significant relationship, again,
probably due to the spread of data across the motivation
categories.
Figure 8 shows how motivation levels were related to a range of
other factors. Statistically significant relationships at the 0.05
level using a Pearsons correlation test are between motivation
levels and, (1) how senior managers motivated the team (Figure
8a), (2) team co-operation (Figure 8b), (3) how other team
members motivated the team (Figure 8e) and (4) the working
environment (Figure 8f). We found no statistically significant
relationship between technology used and motivation (Figure 8c).
This is surprising as developers often indicate that they enjoy
using tools and that using the state-of-art tools is motivating.
Figure 8d shows a statistically significant relationship at the 0.05
level using a Pearsons correlation test between rewards at the end
of the project and motivation. However the relationship is in the
reverse direction to that expected. Figure 8d not only suggests that
most people are not motivated by rewards at the end of the
project, but also suggests that the more motivated developers are
the less important rewards are to them. This could mean that
rewards as a motivator are likely to be effective only with less
motivated developers. However this result needs further
investigation as it may be that rewards may need to be given
before the end of the project to be effective, ie given in immediate
response to performance issues.
The set of results shown in Figure 8 also suggests that very highly
motivated developers may be motivated differently from others.
Several of the tables making up Figure 8 show that motivators
that are effective for most people do not seem to be as effective
for those already highly motivated. This is an interesting result
that needs investigating further.
4. IMPROVING MOTIVATION LEVELS
Given the importance of motivation in relation to turnover and
project success we investigated further factors likely to improve
motivation. We examined over 500 papers published in the
literature and analysed 49 that specifically discuss what motivates
software professional. We extracted the key motivators from each
paper and then identified themes that cut across the papers using
content analysis [2]. We note in Table 1 all those motivators that
appear in 10 or more papers.
The most cited motivator across the 49 published studies is to
identify with the task; twenty different studies found that clear
goals, personal interest, knowing the purpose of the task, how the
task fits in with the whole and producing identifiable piece of
quality work is very important to software engineers. Good
management is also an essential motivator, 16 studies found that,
for example, senior management support, team building skills and
good communication have a major impact. Receiving feedback is
associated with good management and is another important
motivator. A high number of studies found participation, i.e.,
working with others and being involved, motivated employees.
Closely linked to this theme are the motivators: sense of
belonging/supportive relationships and having the need for job
security and a stable environment fulfilled.
Software engineers need a career path where they have
opportunity for advancement, promotion prospects and careful
career plans to fit their specific skill set and needs according to
15 studies. Software engineers like variety in their work; they
enjoy making good use of their skills and being stretched. This is 5. CONCLUSIONS
also shown in the associated motivator that suggests that software Our results suggest that there is a relationship between project
engineers like technically challenging work. Many of these success and motivation. Furthermore that staff turnover is at the
themes are inter-related, for example the motivator heart of this relationship. In particular the answers to our research
developmental needs addressed help to give engineers questions have the following implications:
opportunities to widen their skills and an opportunity to
specialise. RQ1: Is staff turnover related to project success?
Many studies identified rewards and incentives as being an Our results suggest that there may be a relationship between staff
important motivator; software engineers need scope for increased turnover and project success. However this relationship is not
pay and benefits that are linked to performance. An unfair reward clear cut and may vary across projects. This may mean that other
system was found to be extremely de-motivating, for example, factors in combination with staff turnover impact together on
software engineers do not like it when management are given project success. More research is needed to unravel exactly how
rewards for organisational performance and company benefits are turnover impacts on project success. However our results suggest
based on company rank not merit. Recognition is another theme that if staff turnover is controlled, project success is likely to be
closely linked to rewards, here several studies found that improved.
engineers like to be recognised for their high quality work, a RQ2: Are motivation levels related to staff turnover?
good job done based on objective criteria this motivator differs
Our results suggest a clear relationship between staff turnover and
from rewards and incentives which is about making sure that
motivation. However the direction of this relationship is not clear.
there are rewards available more of a carrot.
Our results do not show whether motivation levels are affected by
Table 1: Motivators in Software Engineering turnover or whether turnover is affected by motivation. Indeed it
Motivators References1 Number of may be a symbiotic relationship. Again more research is needed
studies to establish the nature of this relationship. However it is clear that
managers should try to address motivation levels as this is likely
Identify with the task [3-22] 20 to reduce turnover.
RQ3: What factors impact on motivation?
Good management [7, 9, 10, 12, 16, 16 Our empirical results and results from the literature show that a
18-20, 22-29]
range of factors are likely to impact on motivation levels.
Employee participation, [6, 9, 10, 13, 14, 16 However the impact of individual factors is complex and
involvement and working 21, 23, 25, 27, individual factors are likely to impact on different people in
with others 28, 32-36] different ways. For example, our empirical results suggest that
Career Path [3, 4, 7, 11, 12, 15 rewards (a factor reported as moderately important in the
17, 23, 25, 29, literature) impact differently on very highly motivated
32, 35, 42-45] practitioners than on other practitioners. Furthermore our
Rewards and incentives [4, 7, 9, 11-13, 14 empirical results show that a range of factors affect motivation
19, 22-24, 30, 32, levels. For example, our empirical results show that the project
35, 48] itself (the most important factor reported in the literature) does
Variety of Work [3, 7, 11, 12, 17, 14 not impact on motivation levels as much as project managers and
23, 25, 27, 29, senior managers. Our results suggest that managers must
32, 35, 43-45] understand the particular motivational needs of their practitioners
Sense of [5, 9, 16, 18, 23, 14 if they are to motivate them effectively.
belonging/supportive 25, 27, 30, 32, Overall our results suggest that managing the motivation levels of
relationships 36-40] practitioners could have a significant impact on staff turnover and
Recognition. [5, 7, 9, 10, 12- 12 project success. There is much work still to be done in
14, 18, 22, 24, understanding the exact nature of the relationship between these
25, 27] factors. However, it is clear that managers who address the
Development needs [7, 9, 10, 16, 18, 11 motivation of their practitioners reduce the impact of those human
addressed 22, 23, 25, 32, issues frequently cited as contributing to the failure of software
42, 45] projects.
Technically challenging [6, 7, 10, 14, 17, 11
work 18, 24, 26, 40, 6. REFERENCES
46, 47] [1] Agarwal, R. and T.W. Ferratt, Retention and the career
Feedback [3, 6, 8, 13, 16, 10 motives of IT professionals. Proceedings of the ACM
21, 27, 29-31] SIGCPR Conference, 2000: p. 158-166.
Job security/stable [4, 7, 11, 13, 16, 10 [2] Agarwal, R. and T.W. Ferratt, Crafting an HR strategy to
environment 24-26, 32, 41] meet the need for IT workers. Communications of the ACM,
2001. 44(7): p. 58-64.

1
See separate list of references in section 7

33
[3] Agarwal, R. and T.W. Ferratt, Enduring practices for
managing IT professionals. Communications of the ACM,
2002. 45(9): p. 73-79. 1.
[4] Bennatan, E.M., On Time Within Budget, John Wiley and
Sons, 2000.
[5] Bieman, J. What Makes a Software Failure a Page One
Story? Software Quality, Editorial, 2006, 14(2): p. 81-83.
[6] Boehm B. W. Software Risk Management: Principles and
Practices, IEEE Software, 8, 1, 1991, pp.32-41.
[7] Bourzac, K. The Trouble with Software. Technology Review,
2007, 110(1): p. 88
[8] Brooks, F. P. Jr., The Mythical Man Month. Essays on
Software Engineering, Addison Wesley, USA, 1975.
[9] Charettte, R., Why software fails, IEEE Spectrum,
September, 2005, pp.42-49.
[10] Collins, W. R., Miller, K. W., Spielman, B. J. and Wherry,
P.. How Good is Good Enough? An Ethical Analysis of
Software Construction and Use, Communications of the
ACM, 1994, 15(3): p. 81-91.
[11] Dittrich, J.E., D.J. Couger, and R.A. Zawacki, Perceptions of
equity, job satisfaction, and intention to quit among data
processing personnel. Information & Management, 1985.
9(2): p. 67-75.
[12] Frangos, S.A., Motivated humans for reliable software
products. Microprocessors and Microsystems, 1997. 21(10):
p. 605-610.
[13] Garden, A., Behavioural and organisational factors involved
in the turnover of high tech professionals. SIGCPR Comput.
Pers., 1988. 11(4): p. 6-9.
[14] Glass, R. L,. Software Runaways, Prentice-Hall, New York,
1998.
[15] Glass R. L., Facts and Fallacies of Software Engineering,
Addison Wesley, 2002.
[16] IDS, Improving staff retention, IDS HR Studies, IDS Study
765, January 2004.
[17] Jrgensen, M and Molkken-stvold, K. How large are
software cost overruns? A review of the 1994 CHAOS
report, Information and Software Technology, 48, 2006, pp.
297-301.
[18] Langley, N., Software Tests may be Automated but the
Human Element is Crucial, Computer Weekly, 22nd
November 2005
[19] http://www.computerweekly.com/Articles/2005/11/22/21307
2/hot-skills-software-tests-may-be-automated-but-the-
human-element-is.htm
[20] Latimer, D., The Cost of IT Staff Turnover: A Quantitative
Approach, EDUCAUSE Center for Applied
Research,Research Bulletin Volume 2002, Issue 4, 19th
February 2002.
[21] Lee, P.C., The social context of turnover among information
technology professional. Proceedings of the 2002 ACM
SIGCPR Conference on Computer Personnel Research
(Kristiansand, Norway, May 14 - 16, 2002). , 2002: p. 145-
153.
34
[22] Linberg, K. R., Software Developer Perceptions About
Software Project Failure: A Case Study, Journal of Systems
and Software, 49, 1999.
[23] Mak, B.L. and H. Sockel, A confirmatory factor analysis of
IS employee motivation and retention. Information &
Management, 2001. 38(5): p. 265-276.
[24] McConnell, S., Rapid Development, Microsoft Press.
Redmond, Washington, 1996.
[25] Nosek, J. T. and Palvia, P., Software Maintenance
Management: Changes in the Last Decade, Journal of
Software Maintenance: Research and Practice, 2006, 2(3):
p. 157-174.
[26] Poulsen, K. Software Bug Contributed to Blackout, Security
Focus. 11th February 2004
[27] http://www.securityfocus.com/news/8016
[28] Ridings, C.M. and L.B. Eder, An Analysis of IS technical
career paths and job satisfaction. SIGCPR Comput. Pers.,
1999. 20(2): p. 7-26.
[29] Smith, D.C. and H.L. Speight, Antecedents of turnover
intention and actual turnover among information systems
personnel in South Africa Proceedings of the 2006 ACM
SIGMIS CPR conference on computer personnel research:
Forty four years of computer personnel research:
achievements, challenges \& the future . Claremont,
California, USA, 2006: p. 123-129.
[30] Pinto, J. K. and Mandel, S. J., The Causes of Project Failure,
IEEE Transactions on Engineering Management, 34, 7,
November, 1990.
[31] Procaccino, J.D., J.M. Verner, K.M. Shelfer, and D. Gefen,
What do software practitioners really think about project
success: An exploratory study. Journal of Systems and
Software, 2005. 78(2): p. 194-203.
[32] Pressman, Roger, Fear of Trying: The Plight of Rookie
Project Managers, IEEE Software, January-February, 1998.
[33] Rubenstein, D., Standish Group Report: Theres Less
Development Chaos Today, SD Times, 1st March 2007,
Accessed 2nd November 2007
http://www.sdtimes.com/article/story-20070301-01.html
[34] Zvegintzov, N., Software Maintenance News, 1988, 6(8).
7. REFERENCES FOR LITERATURE
REVIEW ON MOTIVATION
[1] Beecham, S., N. Baddoo, T. Hall, H. Robinson, and H.
Sharp, Motivation in Software Engineering: A Systematic
Literature Review. IST journal, 2007 (in press).
[2] Krippendorff, K., Content Analysis An Introduction to Its
Methodology. Sage CommText Series, ed. F.G. Kline. Vol.
5. 1980, Beverly Hills: Sage Publications.
[3] Burn, J.M., J.D. Couger, and L. Ma, Motivating IT
professionals. The Hong Kong challenge Information &
Management, 1992. 22(5): p. 269-280.
[4] Burn, J.M., E.M. Ng Tye, L.C. Ma, and R.S. Poon, Job
expectations of IS professionals in Hong Kong. Proceedings
of the 1994 ACM SIGCPR, Virginia, United States, March
24 - 26, 1994: p. 231-241.
[5] Ferratt, T.W. and L.E. Short, Are information systems people [20] Mata-Toledo, R.A. and E.A. Unger, Another look at
different: an investigation of motivational differences. motivating data processing professionals SIGCPR, 1985.
Management Information Systems Quarterly, 1986. 10(4): p. 10(1): p. 1-7.
377-87. [21] Cheney, P.H., Effects of Individual Characteristics,
[6] Gambill, S.E., W.J. Clark, and R.B. Wilkes, Toward a Organizational Factors and Task Characteristics on
holistic model of task design for IS professionals. Computer Programmer Productivity and Job Satisfaction.
Information and Management, 2000. 37(5): p. 217-228. Information & Management, 1984. 7(4): p. 209-214.
[7] Garden, A., Maintaining the spirit of excitement in growing [22] Frangos, S.A., Motivated humans for reliable software
companies. SIGCPR Comput. Pers., 1988. 11(4): p. 10-12. products. Microprocessors and Microsystems, 1997. 21(10):
[8] Khalil, O.E.M., R.A. Zawacki, P.A. Zawacki, and A. Selim, p. 605-610.
What motivates Egyptian IS managers and personnel: Some [23] Agarwal, R. and T.W. Ferratt, Recruiting, retaining, and
preliminary results. Proceedings of the ACM SIGCPR developing IT professionals: an empirically derived
Conference, 1997: p. 187-192. taxonomy of human resource practices. Proceedings of the
[9] Klenke, K. and K.-A. Kievit, Predictors of leadership style, ACM SIGCPR Conference, 1998: p. 292-302.
organizational commitment and turnover of information
systems professionals. In Proceedings of the 1992 ACM
SIGCPR Conference on Computer Personnel Research APPENDIX 1 EXCERPT FROM
(Cincinnati, Ohio, United States, April 05 - 07, 1992). A. L. QUESTIONNAIRE
Lederer, Ed. SIGCPR '92, 1992: p. 171-183. 7.4 Did the project manager have the authority to choose team
[10] LeDuc, A.L.J., Motivation of programmers. SIGMIS members?
Database, 1980. 11(4): p. 4 - 12. 1. Yes 0. No 3. No project manager 4. some team
[11] Mak, B.L. and H. Sockel, A confirmatory factor analysis of members
IS employee motivation and retention. Information &
Management, 2001. 38(5): p. 265-276.
7.5 Were senior team members consulted about other team
[12] Niederman, F. and M.R. Sumner, Job turnover among MIS member selection?
professionals: an exploratory study of employee turnover.
Proceedings of the 2001 ACM SIGCPR Conference on 1. Yes 0. No
Computer Personnel Research (San Diego, California,
United States). , 2001: p. 11-20.
7.6 How serious was staff turnover during the project?
[13] Peters, L., Managing software professionals. IEMC '03
1. No staff turnover
Proceedings. Managing Technologically Driven
Organizations: The Human Side of Innovation and Change 2. normal turnover for this organization
(IEEE Cat. No.03CH37502). IEEE. 2003, 2003: p. 61-6. 3. managed turnover until the right mix of people was
[14] Procaccino, J.D., J.M. Verner, K.M. Shelfer, and D. Gefen, achieved
What do software practitioners really think about project
success: An exploratory study. Journal of Systems and 4. there was some problem
Software, 2005. 78(2): p. 194-203. 5. very serious problem
[15] Rubin, H.I. and E.F. Hernandez, Motivations and behaviors
of software professionals Proceedings of the ACM SIGCPR, 7.7 Did all the key personnel stay right through the project ?
College park, Maryland, United States 1988: p. 62-71.
1. Yes 0. No
[16] Santana, M. and D. Robey, Perceptions of control during
systems development: effects on job satisfaction of systems
professionals SIGCPR Comput. Pers. , 1995. 16(1): p. 20-34. 7.8 If no, did this negatively impact on the project?
[17] Smits, S.J., E.R. McLean, and J.R. Tanner, Managing high 1. Yes 0. No
achieving information systems professionals. Proceedings of
the 1992 ACM SIGCPR, Ohio, United States, April 05 - 07,
1992, p. 314-327. 7.9 How well did the team members work together?
[18] Tanner, F.R., On motivating engineers. Engineering 1. very well 2. well 3. moderately well 4. not very well
Management Conference, 2003. IEMC '03. Managing 5. did not cooperate with each other
Technologically Driven Organizations: The Human Side of
Innovation and Change, 2003: p. 214-218.
[19] Thatcher, J.B., Y. Liu, and L.P. Stepina, The role of the work 7.10 How high was the motivation of the team members?
itself: An empirical examination of intrinsic motivation's 1. No motivation 2. some motivation 3. average motivation
influence on IT workers attitudes and intentions. Proceedings
4. highly motivated 5. very high motivation
of the ACM SIGCPR Conference, 2002: p. 25-33.

35
Where did the motivation/lack of motivation come from? Tick as 7.13 What was the working environment like?
many as applicable 1. poor 2. worse than average 3. average 4. good 5. excellent
7.11a _ Project manager;
7.11d senior team member; Did the organization consider this project a success?
7.11f other team members; 1. Yes 0. No
7.11b project itself;
7.11e technology used; Do you consider this project was a success?
7.11g reward at the end of project; 1. Yes 0. No
7.11c other: ____________________________________

Was the project a maintenance or development project?

7.12 Did an aggressive schedule affect team motivation? 1. maintenance 2. development
1. Yes 0. No 3. No aggressive schedule

APPENDIX 2
Figure 1. Was the project considered a success by managers?
100

80

60
Count

40

20

0
no yes

was the project a success

Figure 2. Project success and turnover

Was the project a

success? Total

no yes
How serious was none
11 26 37
staff turnover?
normal turnover for this kind of
3 27 30
development
managed turnover until the right mix of
0 2 2
people was achieved
there was some problem 2 1 3
It was a very serious problem 1 5 6
Total 17 61 78

36
 How serious was staff turnover * How
Figure 3. high wassuccess
Project the motivation of the team members Crosstabulation
and motivation
Count
How high was the motivation of the team members
some average highly very highly
no motivation motivation motivation motivated motivated Total
How none 1 6 10 16 3 36
serious normal turnover for this
was 2 2 10 17 0 31
kind of developemnt
staff manged turnover until the
turnover right mix of people was 0 0 1 1 0 2
achieved
there was some problem 0 4 0 0 0 4
It was a very serious
3 1 1 1 0 6
problem
Total 6 13 22 35 3 79

Figure 4. Motivation levels

40

30
Count

20

10

0
no motivation some motivation average motivation highly motivated very highly
motivated

How high was the motivation of the team members

Figure 5. Project motivated team

How high was the motivation of the team members

some average highly very highly
no motivation motivation motivation motivated motivated Total
project itself motivated no 6 5 10 17 2 40
team yes 0 8 12 18 1 39
Total 6 13 22 35 3 79

37
 Figure 6. Project manager motivated team

How high was the motivation of the team members

some average highly very highly
no motivation motivation motivation motivated motivated Total
project manager no 5 6 14 13 3 41
motivated team yes 1 7 8 22 0 38
Total 6 13 22 35 3 79

Figure 7. Staff selection and motivation

How high was the motivation of the team members

some average highly very highly
no motivation motivation motivation motivated motivated Total
The team members no 4 9 11 13 3 40
were consulted about yes 1 4 9 18 0 32
staff selection
Don't know 0 0 1 0 0 1
Total 5 13 21 31 3 73

Figure 8. Factors affecting motivation levels

Figure 8a. Relationship between senior team leader and motivation
senior team leader
motivated team

no yes Total

How high was the no motivation 6 0 6

motivation of the team
some motivation 9 4 13
members
average motivation 19 3 22
highly motivated 20 15 35
very highly motivated 1 2 3
Total 55 24 79

Figure
How well did the team members 8b.
work Relationship
together? * Howbetween team
high was theworking and of
motivation motivation
the team members Crosstabulation

Count
How high was the motivation of the team members
some average highly very highly
no motivation motivation motivation motivated motivated Total
How well did Did not cooperate
1 0 0 0 0 1
the team with each other
members not very well 3 2 0 0 0 5
work together? moderately well 2 6 11 3 0 22
well 0 4 9 17 0 30
very well 0 1 2 15 3 21
Total 6 13 22 35 3 79

38
 Figure 8c. Relationship between technology and motivation

How high was the motivation of the team members

some average highly very highly
no motivation motivation motivation motivated motivated Total
techology used no 4 6 18 18 2 48
motivated team yes 2 7 4 17 1 31
Total 6 13 22 35 3 79

Figureteam
rewards at end of project motivated 8d. Relationship between
* How high was rewards and
the motivation ofmotivation
the team members Crosstabulation

Count
How high was the motivation of the team members
some average highly very highly
no motivation motivation motivation motivated motivated Total
rewards at end of project no 5 11 16 29 0 61
motivated team yes 1 2 6 6 3 18
Total 6 13 22 35 3 79

other team member motivated

Figure 8e. team * How high
Relationship was other
between the motivation of theand
team members team members Crosstabulation
motivation
Count
How high was the motivation of the team members
some average highly very highly
no motivation motivation motivation motivated motivated Total
other team member no 6 9 14 16 3 48
motivated team yes 0 4 8 19 0 31
Total 6 13 22 35 3 79

Figure 8f. Relationship between other team members and working environment

How high was the motivation of the team members

some average highly very highly
no motivation motivation motivation motivated motivated Total
working poor 0 2 0 0 0 2
environment worse than average 3 1 1 3 0 8
average 3 7 9 14 0 33
good 0 2 10 15 3 30
very good 0 0 2 3 0 5
Total 6 12 22 35 3 78

39