Article Preview
TopIntroduction
Accurate forecasts of costs, the duration and quality of software development projects are hardly to achieve (e.g., Barry, Mukhopadhyay, & Slaughter, 2002; Fairly, 2004). The reasons for these overruns arise out of the complexity, conformity, changeability and invisibility of such projects (Brooks, 2010). Whereas the macro level aspects have been widely discussed, consequences for individual decision making are rarely analysed (Abdel-Hamid, Sengupta, & Ronan, 1993). Due to several reasons, the problem of inaccurate forecasts is especially true for the development team performance (Plaza, 2008), which generally has important influence on the overall success. Especially owing to the still existing problems, a lot of research has been done in the field of team design and effectiveness (e.g., Campion, Medsker, & Higgs, 1993; Cohen, Ledford, & Spreitzer, 1996; Li, Li, & Wang, 2009). Hackman and Oldham (1975) elaborated the basics of the Job Characteristics Model, which is according to Fried and Ferris (1987) a rather useful explanation on the individual level. It focuses on task identity and significance, autonomy, feedback and the variety of skills and corresponds to the Team Characteristics Model developed by Strubler and York (2007). Combining both models, the perception of meaningfulness of the work might enable a higher team performance and is itself based on the variety of individual and team skills, task significance and task identity (Stewart, 2006). Empirical studies point out a positive correlation between task characteristics and team performance (Li, Li, & Wang, 2009).
Based on this relationship, literature is primarily analysing optimal task design or team configuration to improve team performance (e.g., Chiu & Chen, 2005). In doing so, cost or time restrictions are oftentimes neglected. Thus implicitly, an unrealistic planning situation is presumed in which management can decide without further constraints and has sufficient lead-time to adjust teams or tasks. Considering software development, this might be an appropriate assumption at the starting point of the project. After the project started, delays oftentimes require to shift work sub-packages to other development teams or to adjust team configurations. Due to preliminary decisions and the requirement of ongoing development, an optimal fit between task characteristics and team members compared to the initial planning before the project’s start is frequently not achievable. In fact, the project management has to take productivity losses into account that occur when team members are shifted to other than the originally planned work packages.
Table 1. Overview of performance measures according to Kasunic (2008)
| Performance measures | Definition |
Project effort(=work effort)
Productivity (=efficiency) | Total project team that is spent on project related activities during the life cycle of the project. Ratio-between project size and project effort. |
| Project duration (=time to market) | Length of project in work days minus work days during work stoppages. |
Schedule predictability
(=schedule overrun/underrun) | Ratio between the project duration deviation and the original estimate of duration |
| Requirements completion ratio (=requirements planned/delivered) | Ratio between the number of satisfied and planned functional requirements |
Post-release defect density
(=defect density after deployment) | Ratio between the number of size relevant unique defects during the first six months after deployment and project size. |