Article Preview
Top1. Introduction
Many organizations providing knowledge intensive business services (KIBS; see Miles et al. 1995) in the ICT sector are software suppliers. In order to survive in the tight competition and also gain better profit, these organizations are needed to provide better customer value than their competitors. This in turn means heavy investments in continuous software development. However, the practice has shown that often these investments have not paid off: anecdotal evidence suggests that half of the ICT projects fail (Ernest-Jones, 2007; Hartmann, 2004).
With the term ‘project’ we refer to the definition of PMI (2008): “A project is a temporary endeavor undertaken to create a unique product, service, or result.” In order to make projects more successful, the organizations must realize in what sense their projects already are successful and in what sense not. Otherwise, project-related targets for improvement are difficult to even find. In other words, success needs to be conceptualized by figuring out the relevant elements of it. The goal of the improvements is to reach increased customer-value, decreased project costs, and win-win situations between customers and suppliers, which, in its turn, increases the competence of KIBS organizations.
The literature of software engineering projects has focused on identifying isolated success factors even though the issues behind the success lie on multidimensional constructions with multidisciplinary factors (Ikonen & Abrahamsson, 2010). While the term of project success is understood in a variety of ways (Agarwal & Rathor, 2006), some definitions taking the customer into account can be agreed to have an established position. Examples of such definitions are the four dimensions of project success of Shenhar et al. (2001) and a definition for success by PMI (2008).
The organizations of software development have not had a standard framework to follow systematically, as Section 2 demonstrates. While the concept of success is often overlooked, the concept of project management is equally little addressed theoretically. Koskela and Howell (2002) argue that there is no explicit theory for project management but rather that the theoretical foundation for project management has emerged from the works of the Project Management Institute in their PMBOK1 guide. As a resolution, Koskela and Howell (2002) propose a novel theory of project, which portrays a project by a transformation view on operations. They suggest that in the transformation view, a project is conceptualized as a transformation of inputs to outputs. A project, then, is managed with a number of principles. As one of the guiding principles, Koskela and Howell (2002) identify the principle of decomposing, which aims at decomposing the total transformation hierarchically into smaller transformations, tasks, and minimizing the cost of each task independently. From the software viewpoint, this is not a novel realization. In the most basic software engineering textbooks (Sommerville, 2007), a software project is viewed conventionally as a problem of decomposition. The challenge that the software project brings into the project concept is the significant role of the human in the process of software development (Boehm, 1981). Moreover, transformation processes in software engineering are not tangible artifacts as in other engineering fields. Cockburn (2002) suggests that what flows in software development is a series of invalidated decisions, which become validated only after they have been implemented. Thereby, it can be suggested that any model aiming at depicting a software project success model should take these characteristics into account.