Defining a conceptual categorization model for agile software development projects



Agile project management has received a lot of attention recently, although much more among practitioners than among researchers. Compared with a traditional approach, it can offer benefits to some projects, but also, it can be inappropriate for others, especially in its native field of software development projects. The question is: How do we determine which approach to use and in which situations? By examining the characteristics of each approach, it is possible to define its appropriateness to a specific project type. This paper focuses on development of a conceptual categorization model for software development projects. It is based on a thorough literature review of the appropriate use of both traditional and agile project management approaches, as well as on a review of the specifics of software development projects. It also builds on existing categorization systems. A total of ten project characteristics were identified, which determine approach appropriateness on an operational level, and a conceptual model of agile software development project characteristics is given and encompasses all of the recognized characteristics. This model represents a first step towards a comprehensive methodology evaluation framework based on project categorization and will serve as a basis for further research in the field of software development project management.

Keywords: agile project management; traditional approach; project characteristics; software development


Today, project management is characterized by a variety of different approaches and perspectives. These differences are best described by various perspectives of researchers who have looked at the field of project management (Bredillet, 2010). But, currently, two approaches are considered as the most opposing ones, especially between practitioners in software development projects.

First, there is a robust traditional approach. This rational and normative approach considers that all projects are relatively simple, predictable, and linear, with clearly defined boundaries that make it easy to plan in detail and follow that plan without many changes (Andersen, 2006; Boehm, 2002; Boehm & Turner, 2003; Camci & Kotnour, 2006; Cicmil, Cooke–Davies, Crawford, & Richardson, 2009; Collyer, Warren, Hemsley, & Stevens, 2010; DeCarlo, 2004; Leffingwell, 2007; Saynisch, 2010; Shenhar & Dvir, 2007; Williams, 2005; Wysocki, 2007). However, more and more, these premises are being questioned. The idea that tasks are mostly hierarchically organized and their relations are linear cannot properly reflect all the complexity and dynamics of today's projects (Cicmil, Williams, Thomas, & Hodgson, 2006; Cicmil et al., 2009; Collyer et al., 2010; Williams, 2005). Furthermore, the assumption that a project is isolated from its environment causes the second major disadvantage of the traditional approach (Aguanno, 2004; Cicmil et al., 2009; Shenhar & Dvir, 2007). Change in any form is the reality of today's business environments and the projects within those environments (Aguanno, 2004; Highsmith & Cockburn, 2001; Leffingwell, 2007; Shenhar & Dvir, 2007; Williams, 2005; Wysocki, 2007). Changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes in the project environment or within the project itself (Collyer et al., 2010; Olsson, 2006). Also, it is sometimes very hard to create a complete project plan at the outset of the project due to an inability to clearly define project goals (Chin, 2004; DeCarlo, 2004; Shenhar & Dvir, 2007).

Therefore, these objections to the traditional project management approach have resulted in the advent of new project management approaches, commonly known as agile, where the benefits of using such an approach for all kinds of projects are highly stressed (Aguanno, 2004; Conforto & Amaral, 2008; Williams, 2005). These approaches have been characterized by their adaptability to changes during the project life cycle and to different projects in general (Aguanno, 2004; Boehm & Turner, 2003; DeCarlo, 2004; Shenhar, 1999; Shenhar & Dvir, 2007). Change is inevitable, so new approaches embrace changes and acknowledge that it is almost impossible to create a complete project plan at the beginning of the project (Andersen, 2006; Leffingwell, 2007; Shenhar & Dvir, 2007; Williams, 2005). This is the reason why new approaches emphasize project execution before all, in contrast to the traditional approach in which an emphasis is on thorough planning (Chin, 2004; DeCarlo, 2004; Leffingwell, 2007; Manifesto, 2001; Williams, 2005).

Furthermore, new approaches are not only about pure process following, but more about communication and collaboration between project team members (Aguanno, 2004; Cockburn & Highsmith, 2001; Collyer et al., 2010; Coram & Bohner, 2005; DeCarlo, 2004; Highsmith & Cockburn, 2001; Williams, 2005). Team members are much more involved in decision-making, and communication is both formal and informal (Aguanno, 2004; Cockburn & Highsmith, 2001; Haas, 2007; Highsmith & Cockburn, 2001; Williams, 2005). All of this requires a change in the way of thinking (DeCarlo, 2004; Shenhar & Dvir, 2007) and, consequently, changes within the specific organization that tries to embrace any of the new approaches (Aguanno, 2004; Boehm & Turner, 2005; Chin, 2004; Cockburn & Highsmith, 2001; DeCarlo, 2004; Highsmith, 2004; Lawrence & Yslas, 2006; Leffingwell, 2007).

There are also opponents of the agile approach who usually notice that there is still a lack of empirical evidence of successful application of the agile methods (Coram & Bohner, 2005; Conforto & Amaral, 2008; Leybourne, 2009). But, lately, there has been more and more evidence from empirical research of the successful application of the agile approach (Chow & Cao, 2008; Fogelstrom, Gorschek, Svahnberg, & Olsson, 2010). One such study (Chow & Cao, 2008) found that critical success factors for the agile approach include appropriate use of agile methods, a highly qualified project team, and right delivery strategy, whereas an appropriate management process, organizational environment, and customer involvement are factors that may contribute to project success.

So, today, an increasing number of researchers are stressing the fact that “one size does not fit all.” Projects do differ, according to a larger number of characteristics, and there is one approach that is applied to the project and should be carefully selected and adapted based on characteristics that do matter for that selection (Aguanno, 2004; Chin, 2004; Shenhar, 1998; Shenhar & Dvir, 2007; Wysocki, 2007). Both traditional and agile approaches have their advantages and disadvantages, so it is not possible to uniformly assert that one approach is better than the other, and it is often necessary to combine both approaches (Aguanno, 2004; Andersen, 2006). One should bear in mind the appropriateness of an approach to a specific project (Boehm, 2002), because it is possible that an inappropriate approach will not help achieve project success; on the contrary, it could cause additional problems and lead to project failure (Shenhar, 1999).

Therefore, the main question arises: Which approach is more appropriate to use and in which situations? The main goal is, therefore, to form an evaluation framework for the use of specific methods, tools, and techniques on a given project. This evaluation framework should be primarily focused on software development projects as they are of primary interest for agile project management use, and project management is highly contextual.

Research Approach

This paper represents part of the ongoing research aimed at providing an evaluation framework for the use of specific methods, tools, and techniques on a given project. To provide such a framework, several steps should be considered.

First, and the focus of this paper, is a definition of the situation in which a given approach is most appropriate to use. The focus of this paper is within software development projects, so situations will not be only bound by characteristics of the specific approach, but also by the characteristics of this specific area of application. Both sets of characteristics will form the basis for project categorization with the purpose of determining the appropriateness of such approach, which is the focus of this paper. Therefore, one of the greatest challenges is to define for which kinds of projects the approach is most appropriate and, before all, which project characteristics are important for that decision (Williams, 2005).

In order to define situational characteristics (i.e., characteristics of the projects), we first deal with characteristics of the different approaches and descriptions of their home ground. This is later revised with the discussion on the specifics of software development projects and reviews of the existing categorization system. The complete analysis is done through an extensive literature review.

Finally, all identified characteristics have been combined in a conceptual categorization model for software development projects.

The final goal of the research, a project management methodology evaluation framework, should build on the defined set of characteristics. Each tool and technique used within the methodology should be evaluated for its appropriateness. Similarly, each project should be evaluated based on the same set of characteristics. Going from the assumption that a project management methodology used in a company is defined by its methods, tools, and techniques, this will form an evaluation framework for methodology within a specific organization. As a final step toward the goal, an evaluation framework should be verified, and this will be done by testing an evaluation framework in a real environment.

Literature Review

Home Ground for Different Approaches

Projects that fit into the traditional project management thinking are those with clear initial user requirements and with clear project goals, and hence, with a very low level of uncertainty (Coram & Bohner, 2005; DeCarlo, 2004; Fernandez & Fernandez, 2008; Wysocki, 2007). Such projects are expected to have very low requirements change rates (Shenhar & Dvir, 2007; Wysocki, 2007) and it is not necessary to involve end users heavily in the project (Coram & Bohner, 2005; Wysocki, 2007). In these situations, the emphasis will be on planning and, based on the initial plan, on a predictable and linear following of that project plan with the goal of optimization of project activities and efficiency in their execution (Boehm, 2002; DeCarlo, 2004; Shenhar & Dvir, 2007). A traditional approach is also appropriate for projects in which formal documentation is required any time during the project (Boehm, 2002; Coram & Bohner, 2005). Typical projects would include operative routine projects with a predictable and verified way on how to accomplish project goals, like typical construction or engineering projects (Chin, 2004; DeCarlo, 2004; Wysocki, 2007).

It is also noted that bigger projects, no matter if the size is determined by the number of project team members (Aguanno, 2004; Boehm, 2002; Boehm & Turner, 2003; Cockburn, 2000; Fowler, 2005; Highsmith, 2004), or by the amount and complexity of clearly defined requirements (Boehm, 2002; Coram & Bohner, 2005), or even by duration (Coram & Bohner, 2005), are more appropriate for a traditional project management approach. As already stressed, one of the key success factors of the approach selection is organizational environment. Generally speaking, an organization can be unprepared or even unwilling to implement new approaches, and the only way to proceed in such situations is to use existing processes, which, in the majority of cases, is the traditional approach (Conforto & Amaral, 2008; Lawrence & Yslas, 2006; Wysocki, 2007). Furthermore, bigger organizations, with a number of organizational units involved in single projects, are more ready to use the traditional approach (Chin, 2004) because this approach puts an emphasis on control of work. For the same reason of control, and the fact that importance of the human factor is not that accentuated in the traditional approach, it is recommended to use a traditional approach if team members do not agree on a different approach; if team members are less experienced; if a fluctuation of team members is expected during the course of the project; or, if the project manager is not in daily contact with team members (Coram & Bohner, 2005). Finally, it is recommended to use a traditional approach if system criticality is one of the key characteristics of the project, when consequences of system failure can be very serious (Boehm & Turner, 2003; Cockburn, 2000).

On the other hand, the agile project management approach is intended primarily for creative and innovative projects, such as research projects, new innovative product development projects, or process improvement projects (Chin, 2004; Conforto & Amaral, 2008; Highsmith, 2004; Wysocki, 2007). All such projects are characterized by a high level of uncertainty, unclear project goals, or incomplete and unpredictable requests, for which it could be assumed will be significantly changed during the course of the project (Aguanno, 2004; Boehm, 2002; Boehm & Turner, 2005; Cockburn, 2000; Conforto & Amaral, 2008; Coram & Bohner, 2005; DeCarlo, 2004; Haas, 2007; Highsmith, 2004; Leffingwell, 2007; Shenhar & Dvir, 2007; Williams, 2005; Wysocki, 2007). Again, due to constant change requests, projects are organized in an iterative way, non–linear, with frequent modifications and updates of the project plan and require close and frequent collaboration with end users during the project (Boehm 2002; Haas, 2007; Wysocki, 2007). This iterative approach also helps in fast implementation (Benediktsson & Dalcher, 2005), which is required due to tight time constraints (Boehm & Turner, 2005; Chin, 2004; DeCarlo, 2004; Leffingwell, 2007; Williams, 2005; Wysocki, 2007), and for the reason of better project monitoring and controlling, requirements are organized into functional parts (Boehm & Turner, 2005; Haas, 2007). To conclude, a typical agile project would be a smaller stand-alone software development project, most often within the single organization, and usually with an emphasis on the user interface (Boehm 2002; Boehm & Turner, 2003; Boehm & Turner, 2005; Coram & Bohner, 2005).

Contrary to the traditional approach, the impact of the human factor and especially communication between project team members, are accentuated to the point that it is recommended that project team members should be very good, if not the best in the field within the project reach or within the company (Boehm, 2002; Cockburn, 2000; Cockburn & Highsmith, 2001; Coram & Bohner, 2005; Highsmith, 2004). Highsmith (2004) says that ability and self-discipline are among the most important team member's characteristics, whereas Reich et al. (2008) list motivation and team spirit as most important. Boehm and Turner (2003) build on basic levels set up by Cockburn and characterize project team members according to their understanding of software methods. The recommendation is also that those team members should work on a common location in smaller teams (Chin, 2004; Cockburn & Highsmith, 2001; Coram & Bohner, 2005; Haas, 2007; Lawrence & Yslas, 2006; Leffingwell, 2007). The consequence is that agile appropriate projects do not put an emphasis on extensive documentation; therefore, project knowledge is mainly tacit (Boehm 2002; Chin, 2004; Haas, 2007).

Table 1: The differences between the traditional and agile approaches.

Characteristic Traditional approach Agile approach
Requirements clear initial requirements; low change rate creative, innovative; requirements unclear
Users not involved close and frequent collaboration
Documentation formal documentation required tacit knowledge
Project size bigger projects smaller projects
Organizational support use existing processes; bigger organizations prepared to embrace an agile approach
Team members not accentuated; fluctuation expected; distributed team collocated team; smaller team
System criticality system failure consequences are serious less critical systems
Project plan linear complex; iterative

Summarizing all the characteristics mentioned above (Table 1), it is possible to clearly distinguish those that define appropriateness of the selected approach. The last mentioned difference is quality of team members, but, first of all, there is uncertainty. Uncertainty implies the lack of information needed to execute some of the project activities or the whole project (Atkinson et al., 2006; McLain, 2009; Perminova, Gustafsson, & Wikstrom, 2008; Tatikonda & Rosenthal, 2000) and is inevitable for most of the projects (Atkinson et al., 2006; De Meyer, Loch, & Pich, 2002). It also implies constant change during the course of the project (De Meyer et al., 2002). Uncertainty could be distinguished according to the characteristics of the missing information, so De Meyer et al. define four levels of uncertainty: variation, expected uncertainty, unexpected uncertainty, and chaos (De Meyer et al., 2002). If these uncertainty levels are taken and replicated to project management approaches, it could be said that variation would fit into the expectations of the traditional approach, whereas any other level would require a higher level of adaptation (i.e., would fit more into the idea of the agile approach). First, two uncertainty levels would be handled in a traditional approach by applying risk management (Atkinson et al., 2006; De Meyer et al., 2002; Perminova et al., 2008; Project Management Institute, 2008). It is also the fact that for most projects one uncertainty level is dominant (De Meyer et al., 2002).

As already stated, one of the causes of uncertainty, especially in the early phases of a project, is an unclear or incomplete project goal (Atkinson et al., 2006; Chin, 2004; DeCarlo, 2004; Gemino et al., 2007; McLain, 2009; Shenhar & Dvir, 2007; Williams, 2005; Wysocki, 2007; Xia & Lee, 2005), or even an unclear way of how to reach the project goal (McLain, 2009; Tatikonda & Rosenthal, 2000; Williams, 2005; Wysocki, 2007). The reason could be in the complexity of the software development product or in its novelty, which is again connected to the lack of knowledge and experience (McLain, 2009; Tatikonda & Rosenthal, 2000; Yetton, Martin, Sharma, & Johnston, 2000). Unclear project goals will not only have influence at the start of the project but will certainly cause changes during the course of the project, which could be reflected in any element of the project plan (Wysocki, 2007). The probability that changes will happen during the project is higher if the product and project novelty is higher (Yetton et al., 2000). Generally, changes during the project life cycle can be caused not only by unclear project goals, but by changes in other factors as well (e.g., tools, materials, or other projects or activities) (Collyer et al., 2010; Gemino et al., 2007; Olsson, 2006; Sauer, Gemino, & Reich, 2007).

One of the most frequently used project characteristics is project size. Because it is so frequently used, the project size attribute can be used for different purposes and with different meanings and definitions. It is therefore common to use project size in terms of the total project budget or financial value (Gemino et al., 2007; Martin et al., 2005; Olsson, 2006; Patanakul et al., 2006; Payne & Turner, 1999; Sauer et al., 2007; Wysocki, 2007; Yang, O'Connor, & Wang, 2006), in terms of total project duration (Gemino et al., 2007; Martin et al., 2005; Patanakul et al., 2006; Sauer et al., 2007; Wysocki, 2007), or in terms of total project workload (Benediktsson & Dalcher, 2005; Dalcher & Benediktsson, 2006; Gemino et al., 2007; Sauer et al., 2007), or in terms of project team size (Boehm & Turner, 2003; Cockburn, 2000; Gemino et al., 2007; Highsmith, 2004; Martin et al., 2005; Sauer et al., 2007). But, considering software development projects, it is common to use either total workload or to measure the project size according to lines of source code or according to number of function points (Benediktsson & Dalcher, 2005; Dalcher & Benediktsson, 2006; Fenton & Neil, 1999; Martin et al., 2005; Pressman, 2001; Tatikonda & Rosenthal, 2000). Research has shown that the size of the project, measured as the total workload, was a better predictor of success than the use of the other project size measures, such as budget, duration, or project team size (Sauer et al., 2007).

Software Development Projects

Software development projects are defined mostly by characteristics of the software product (i.e., by the result of the software development project). Brooks (1987) states that the basic characteristics of the software product are: complexity, conformity, changeability, and invisibility. Fairley (2009) builds on those characteristics and adds teamwork and intellectual work. Furthermore, Pressman (2001) claims that a software product is more logical than a physical system; that software development is more like new product development than classical engineering build; it usually does not wear out; and, finally, it is still mostly built according to a specific need. Many other authors (Aguanno, 2004; Leffingwell, 2007; Wysocki, 2006) differentiate between software development projects and other projects, by their logical, immaterial nature, and frequent changes of both goals and technology. Summarizing the reasons why software development projects are differentiated, Stepanek (2005) lists, in a hierarchical way, complexity, abstract nature, requirements incompleteness, technology change, and immaturity and unavoidable requirements change. Furthermore, because software development projects are by their nature more like new innovative product development (Aguanno, 2004; Highsmith, 2004; Pressman, 2001), and in such situations the project goal is only rudimentarily known or set up very widely, they can bolster creativity of the project team members in reaching the final goal, and consequently, intensive communication between team members is also stressed (Fairley, 2009; Reich, Sauer, & Wee, 2008; Simon, 2006).

To add on to already identified project characteristics that contribute to defining appropriateness of the specific approach, software development projects are mainly characterized by their complexity (McConnell, 1993). Even though complexity is very often mentioned in the context of project characteristics, it is not uniformly or completely defined in the existing literature (Aitken & Crawford, 2007; Muller & Turner, 2007; Williams, 1999; Xia & Lee, 2005). Baccarini (1996) defines complexity as something composed of many interconnected parts and is possible to express in the sense of differentiation and/or interdependence. Furthermore, Cicmil et al. (2009) define complexity as a certain dynamic in time, which can be simultaneously stable and unstable, predictable and unpredictable, known and unknown, certain and uncertain.

Within the project, we can discuss several types of complexity. First is structural complexity (Saynisch, 2010a; Williams, 1999; Williams, 2005; Xia & Lee, 2005), which is related to number of project elements and their interdependence, and it could be said that this type of complexity emerges directly from product complexity. Tatikonda and Rosenthal (2000) call such complexity simply project complexity. Structural complexity can be discussed in the terms of the product size (Baccarini, 1996; Shenhar & Dvir, 2007; Williams, 1999; Williams, 2005), expressed as the number of project elements and their interdependence or in the terms of number and interdependence of the project activities. Connection between product size and number of project activities is therefore obvious and linear.

Beside structural complexity, there also exists organizational complexity (Aitken & Crawford, 2007; Baccarini, 1996; Cicmil et al., 2009; Jensen, Johansson, & Lofstrom, 2006; Williams, 1999). Organizational complexity is related primarily to the number of project stakeholders—from team members to project sponsor—and to their relation to the project and their interrelation. All of the organizational complexity is reflected in communication between stakeholders and, with an increase in stakeholder number, communication increases as well as organizational complexity. Communication is easier if a team is collocated, and if not, this contributes to an increase of organizational complexity due to complex communication need (Chin, 2004; Cockburn, 2000; Cockburn, 2006; Coram & Bohner, 2005; Evaristo & van Fenema, 1999; Haas, 2007; Lawrence & Yslas, 2006; Leffingwell, 2007).

Existing Categorization Systems

Currently, the majority of existing categorizations have been developed either within the academic community for the specific purpose of single research (Williams, 2005), such as the work by Shenhar (1998), Evaristo and van Fenema (1999), Patanakul, Shenhar, and Milosevic (2006), and Aitken and Crawford (2007), or they are developed within companies for the purpose of categorizing projects in that company. Nevertheless, some of the proposed categorizations propose comprehensive systems for categorizing projects with a specific focus. The categorization system proposed by Shenhar and Dvir (2007) offers a four-dimensional model for categorizing every project. They have proposed dimensions of novelty, technology, complexity, and pace as universal characteristics of every project and claim that project management style, and even a management style in general, should be adapted for the specific project according to determined values of each dimension. Even though it offers comprehensive coverage for all kinds of projects, it also offers a high, strategic, level overview; therefore, it is not always easy to measure each dimension for the project at hand on the operational level. Furthermore, if we narrow the focus on the projects to one application area, the question arises: Is it possible to use more specific attributes in order to determine proper project management style and, on a more operational level, appropriate methods and techniques? On the other hand, the categorization proposed by Boehm and Turner (2003) focuses more on selecting and adapting software development methods and techniques, agile or traditional ones. It encompasses dimensions of dynamism in terms of change of requirements, criticality, personnel in terms of method understanding, project size measured by number of personnel, and company culture. However, from the discussion about approach appropriateness, it is obvious that it could benefit from a more comprehensive set of characteristics and from additional managerial view.

Based on existing project categorizations, it is possible to add additional characteristics that contribute to distinguishing different project categories, and some of them were already listed. Not listed is system criticality, which measures the consequences of system failure (Cockburn, 2000). Furthermore, customer availability and involvement, especially in the case of unclear goals, are of great importance for successful project completion, and timely customer involvement becomes critical (Reich et al., 2008; Yetton et al., 2000). Customers assigned to a project should be, according to Boehm and Turner (2002; 2003), collaborative, representative, authorized, committed, and knowledgeable.

According to Shenhar and Dvir (2007), novelty dimensions refer to the extent of the product newness to the existing market or to the existing customer, and changes in the project. Similarly, Boehm and Turner (2003) define dynamism as the percentage of requirement changes per month, and some research has found that almost every project undergoes some goal changes during its life cycle. The number of changes during a project life cycle can be even significant (Sauer et al., 2007), especially if an iterative approach, which is the basis of the agile approach, is applied (Dalcher & Benediktsson, 2006). It could be also concluded that the number of changes is proportional to project complexity and uncertainty (Dalcher & Benediktsson, 2006; Wysocki, 2007).

The next characteristic is technological uncertainty, which is mostly related to what extent is new technology used in the implementation of a specific project (Martin, Pearson, & Furumo, 2005; Shenhar & Dvir, 2007; Tatikonda & Rosenthal, 2000; Wysocki, 2007). The use of technology in projects is related to the knowledge, ability, and utility needed to develop and enable use of the final product (Shenhar & Dvir, 2007), and it can be seen through the lens of uncertainty, which new technology brings along or through the lens of complexity that causes that uncertainty. In the case of software development projects, it is also common to use technological complexity in terms of the use of software development tools and technology (Aguanno, 2004; Boehm & Turner, 2003; Gemino, Reich, & Sauer, 2007; Stepanek, 2005; Xia & Lee, 2005).

Last, but not least, is the characteristic, pace, which includes the need and importance of delivering project results in a specified time and actually determines the time available for the project (Chin, 2004; Shenhar & Dvir, 2007; Williams, 2005).

A Conceptual Categorization Model for the Software Development Projects

In summary, it is obvious that software development projects can be defined using their specific characteristics, as well as characteristics specific to determining appropriateness of a specific project management approach. These characteristics determine which approach to use and include those that are possible to measure empirically. It encompasses categorization given by Shenhar and Dvir (2007) in the dimensions of pace and technological uncertainty, whereas complexity is disseminated in structural and organization complexity. Based on a previous discussion on project complexity, it is obvious that these are two quite different types of complexity. Furthermore, the dimension of novelty from Shenhar and Dvir (2007) is replaced with the project goals clarity, which has proved to be more in line with the concept of the agile approach and even easier to understand and measure on an operational level, when deciding on appropriateness of approach. Also, as discussed, uncertainty is not only considered a technological uncertainty, but uncertainty in goals and constant changes contribute to the overall project uncertainty. Categorization from Boehm and Turner (2003) has been used to extend the model in order to accommodate an easier decision on the approach to be used. The dimensions of dynamism, product criticality, and team members’ quality have been added to the model, accordingly. Dimension of project size has been added, but it does not include number of team members because it is measured within the organizational complexity, where it adds to the complexity of communication. Project size equals the size of the software development project, measured in a total workload or in lines of code or number of function points, as discussed in the section on project size. Finally, the dimension of customer availability is added to the complete impact of human resources on the project, which is especially stressed in an agile approach as one of the success factors (Chow & Cao, 2008).

The characteristics of the software development projects listed in Table 2 are not the final set of characteristics that could define any project and even a software development project. Many other characteristics could be found, which define projects, and a very comprehensive overview is given by Crawford, Hobbs, and Turner (2005). However, the paper discusses the characteristics that, according to specifics of the software development projects and software products, make a differentiation between those projects. Characteristics are discussed on a high level, with drill down to a more detailed and more operational level, which enable their measurement. For some of them, like complexity and uncertainty, it made sense to discuss one level of characteristics lower in order to offer some measurement because they were usually considered as the most abstract characteristics. Furthermore, measures for most of the characteristics are composite ones, comprised of more than one measure, which is the usual practice for abstract and complex characteristics (Crawford et al., 2005).

Table 2: Characteristics used for the conceptual categorization model.

Characteristic Description Representative Authors
Structural complexity number of project elements and their interdependence; emerges directly from product complexity Baccarini, 1996; Shenhar & Dvir, 2007; Williams, 2005; Xia & Lee, 2005
Organizational complexity number of project stakeholders, their relation to the project, and their interrelation Aitken & Crawford, 2007; Baccarini, 1996; Cicmil et al., 2009; Jensen, Johansson, & Lofstrom, 2006; Williams, 1999
Uncertainty lack of information needed to execute some of the project activities or the whole project Atkinson et al., 2006; De Meyer et al., 2002; McLain, 2009; Perminova, Gustafsson, & Wikstrom, 2008; Pich et al., 2002; Tatikonda & Rosenthal, 2000
Technological uncertainty to what extent is new technology used in implementation of specific project Martin et al., 2005; Shenhar & Dvir, 2007; Tatikonda & Rosenthal, 2000; Wysocki, 2007
Project goals clarity unclear or incomplete project goal or unclear way how to reach project goal Atkinson et al., 2006; Chin, 2004; DeCarlo, 2004; Gemino et al., 2007; McLain, 2009; Shenhar & Dvir, 2007; Tatikonda & Rosenthal, 2000; Williams, 2005; Wysocki, 2007; Xia & Lee, 2005
Dynamism / changes percentage of requirements changes per month Boehm & Turner, 2003; Collyer et al., 2010; Dalcher & Benediktsson, 2006; Sauer et al., 2007;
Project size total workload, or lines of source code or number of function points Dalcher & Benediktsson, 2006; Gemino et al., 2007; Sauer et al., 2007; Tatikonda & Rosenthal, 2000
Pace time available for the project Chin, 2004; Shenhar & Dvir, 2007; Williams, 2005
Team members quality method understanding and use Cockburn, 2000; Boehm & Turner, 2003
Customer availability collaborative, representative, authorized, committed, and knowledgeable Boehm & Turner, 2003; Reich et al., 2008
Product criticality consequences of the system failure Cockburn, 2000; Boehm & Turner, 2003

This conceptual model of software development projects characteristics is actually a categorization system and is organized according to recommendations and best practices found in research on categorization systems by Crawford et al. (2005; 2006). Creation of the categorization system is generally not a simple thing to do, and they are usually not just simple one-dimensional models. On the contrary, categorizations represent complex systems in which attributes can be organized hierarchically; parallel or several attributes can constitute one complex attribute, as was the case with uncertainty and complexity. It is important to stress that an efficient categorization system will include only those attributes needed to determine requested categories and rules to determine those attributes; according to Archibald (2005), it will be organized hierarchically.

Based on an overview given in a literature review, and on the characteristics listed in Table 2, a proposed conceptual categorization model of software development projects is shown in a Figure 1.

Categorization model for software development projects

Figure 1: Categorization model for software development projects.

There are total of 10 characteristics shown in the model in Figure 1 that determine which approach to use. It is visible in Figure 1 that two higher-level characteristics were disseminated to lower-level characteristics; namely, uncertainty is shown with technological uncertainty, project goals clarity, and dynamism/changes, whereas complexity is composed of structural complexity and organizational complexity, as described in the section about uncertainty. The other five characteristics reflect the previously discussed ones: related to product is product criticality and partially, project size; pace reflects the need for timely project delivery, and two final characteristics, customer availability and team member quality, reflect the types of stakeholders available for the project.

Characteristics are shown with the directed arrows, in a direction of higher values of specific characteristics, so in that way the outer edge of the chart determines which project is appropriate for the agile project management approach. Agile is therefore more appropriate for projects with the lower product criticality, both organizational and structural complexity and smaller ones, whereas, at the same time for those projects with higher uncertainty, with accentuated human impact factor and those needed to be delivered quickly. A typical project appropriate for an agile project management approach would cover the spider chart closer to the edges, whereas projects more appropriate for a traditional approach would cover the chart closer to the center, as shown in the examples in Figure 2.

Examples of the differences between traditional and agile projects

Figure 2: Examples of the differences between traditional and agile projects.

The categorization model for software development projects presented in Figure 1 provides a basis for further research of the appropriateness of approach use. It provides a starting point for the evaluation of project management methodology that is executed on a project portfolio within the organization. Each method and technique, or any other part of the methodology, could be evaluated according to these characteristics, and that could determine the appropriateness of that specific part of the methodology for a certain project category. Also, that initial mapping to characteristics could be used to improve a specific method, to be more usable if applied to those kinds of projects. It would definitely be interesting to empirically test if the methodology that is adaptive to a specific project according to project characteristics will be more efficient. All of these represent possible ways to extend the research.


This paper represents part of the ongoing research on the framework for methodology evaluation for software development projects, based on project categorization. The paper looks at the characteristics of both traditional and agile project management and discusses situations in which it is more appropriate to use one or the other approach. Furthermore, the extensive literature review is continued with the detailed discussion on the attributes that define software development projects, which could be used for determining approach appropriateness. Based on this, a model is proposed that encompasses all of the recognized characteristics that do contribute to the differentiation of software development projects.

The next step in this research will be to empirically test which of the attributes are used and how one can adapt a project management methodology for a specific project, specifically in environments in which one approach prevails and in environments in which both traditional and agile approaches are used. Furthermore, no final values for each characteristic are given. This presents further possibilities for research and model improvement, as with the use of the characteristics usually come the values of each characteristic, and empirical research would give the answer as to the preferred way of measuring each characteristic. A possible recommendation for the final model would be to propose the same number of possible values for characteristics, but this is not mandated.

Finally, this categorization model represents one step forward in defining a set of characteristics to be used for the project and for the method at hand, on the operational level.


Aguanno, K. (2004). Managing agile projects. Lakefield, Canada: Multi–Media Publications Inc.

Aitken, A., & Crawford, L. (2007). A study of project categorisation based on project management complexity. Proceedings of IRNOP VIII, UK.

Andersen, E. S. (2006). Perspectives on projects. Proceedings of the PMI Research Conference 2006, Canada.

Archibald, R. D. (2005). The purposes and methods of practical project categorization. International

Project/Program Management Workshop 5, France. Atkinson, R.. Crawford, L., & Ward, S. (2006). Fundamental uncertainties in projects and the scope of project management. International Journal of Project Management, 24(8), 687–698.

Baccarini, D. (1996). The concept of project complexity: A review. International Journal of Project Management, 14(4), 201–204.

Benediktsson, O., & Dalcher, D. (2005). Estimating size in incremental software development projects, IEE Proceedings–Software, 152(6), 253–259.

Bredillet, C. N. (2010). Blowing hot and cold on project management. Project Management Journal, 41(3), 4–20.

Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), 64–69.

Boehm, B., & Turner, R. (2003). Balancing agility and discipline: A guide for the perplexed. Boston, MA: Addison Wesley.

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30–39.

Brooks, F. P. Jr. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19.

Camci, A., & Kotnour, T. (2006). Technology complexity in projects: Does classical project management work? PICMET 2006 Proceedings, Turkey, 2181–2186.

Chin, G. (2004). Agile project management: How to suceed in the face of changing project requirements. New York: AMACOM.

Chow, T., & Cao, D. (2008). A survey study of critical success factors in agile software projects. The Journal of Systems and Software, 81(6), 961–971.

Cicmil, S., Williams, T., Thomas, J., & Hodgson, D. (2006). Rethinking project management: Researching the actuality of projects. International Journal of Project Management, 24(8), 675–686.

Cicmil, S., Cooke–Davies, T., Crawford, L., & Richardson, K. (2009). Exploring the complexity of projects: Implications of complexity theory for project management practice. Newtown Square, PA: Project Management Institute.

Cockburn, A. (2000). Selecting a project's methodology. IEEE Software, 17(4), 64–71.

Cockburn, A. (2006). Agile software development: The cooperative game. Second Edition. Boston, MA: Addison Wesley Professional, Pearson Education, Inc.

Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131–133.

Collyer, S., Warren, C., Hemsley, B., & Stevens, C. (2010). Aim, fire, aim: Project planning styles in dynamic environments. Project Management Journal, 41(4), 108–121.

Conforto, E. C., & Amaral, D. C. (2008). Evaluating an agile method for planning and controlling innovative projects. Project Management Journal, 33(4), 4–14.

Coram, M., & Bohner, S. (2005). The impact of agile methods on software project management. Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer–Based Systems, USA.

Crawford, L., Hobbs, J. B., & Turner, J. R. (2005). Project categorization systems: Aligning capability with strategy for better results. Newtown Square, PA: Project Management Institute.

Dalcher, D., & Benediktsson, O. (2006). Managing software development project size: Overcoming the effort–boxing constraint. Project Management Journal, 37(2), 51–58.

DeCarlo, D. (2004). eXtreme Project Management. San Francisco: Jossey–Bass.

De Meyer, A., Loch, C. H., & Pich, M. T. (2002). Managing project uncertainty: From variation to chaos. MIT Sloan Management Review, Winter 2002, 60–67.

Evaristo, R., & van Fenema, P. C. (1999). A typology of project management: Emergence and evolution of new forms. International Journal of Project Management, 17(5), 275–281.

Fairley, R. E. (2009). Managing and leading software projects. Hoboken, NJ: IEEE Computer Society, John Wiley & Sons, Inc.

Fenton, N. E., & Neil, M. (1999). Software metrics: Successes, failures and new directions. The Journal of Systems and Software, 47(2–3), 149–157.

Fernandez, D. J., & Fernandez, J. D. (2008). Agile project management: Agilism versus traditional approaches. Journal of Computer Information System, 49(2), 10–17.

Fogelstrom, N. D., Gorschek, T., Svahnberg, M., & Olsson, P. (2010). The impact of agile principles on market–driven software product development. Journal of Software Maintenance and Evolution: Research and Practice 22(1), 53–80.

Gemino, A., Reich, B. H., & Sauer, C. (2007). A temporal model of information technology project performance. Journal of Management Information Systems, 24(3), 9–44.

Haas, K. B. (2007). The blending of traditional and agile project management. PM World Today–May 2007, 9(5).

Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34(9), 120–122.

Highsmith, J. (2004). Agile project management. Boston, MA: Addison–Wesley.

Jensen, C., Johansson, S., & Lofstrom, M. (2006). Project relationships: A model for analyzing interactional uncertainty. International Journal of Project Management, 24(1), 4–12.

Lawrence, R., & Yslas, B. (2006). Three–way cultural change: Introducing agile within two nonagile companies and a non–agile methodology. Proceedings of AGILE 2006 Conference, USA.

Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Addison–Wesley, Pearson Education, Inc.

Leybourne, S. A. (2009). Improvisation and agile project management: A comparative consideration. International Journal of Managing Projects in Business, 2(4), 519–535.

Manifesto for Agile Software Development (2001). Retrieved from

Martin, N. L., Pearson, J. M., & Furumo, K. A. (2005). IS project management: Size, complexity, practices and the project management office. Proceedings of the 38th Hawaii International Conference on System Sciences-2005Ö¾ USA.

McConnell, S. (1993). Code complete: A practical handbook of software construction. Redmond, WA: Microsoft Press.

McLain, D. (2009). Quantifying project characteristics related to uncertainty. Project Management Journal, 40(4), 60–73.

Müller, R., & Turner, J. R. (2007). Matching the project manager's leadership style to project type. International Journal of Project Management, 25(1), 21–32.

Olsson, N. O. E. (2006). Management of flexibility in projects. International Journal of Project Management, 24, 66–74.

Patanakul, P., Shenhar, A. J., & Milosevic, D. (2006). Why different projects need different strategies. Proceedings of the PMI Research Conference 2006, Canada.

Payne, J. H., & Turner, J. R. (1999). Company–wide project management: The planning and control of prgorammes of projects of different type. International Journal of Project Management, 17(1), 55–59.

Perminova, O., Gustafsson, M., & Wikstrom, K. (2008). Defining uncertainty in projects: A new perspective. International Journal of Project Management, 26(1), 73–79.

Pich, M. T., Loch, C. H., & De Meyer, A. (2002). On uncertainty, ambiguity, and complexity in project management. Management Science, 48(8), 1008–1023.

Pressman, R. S. (2001). Software engineering: A practitioner's approach. 5th edition. New York: McGraw–Hill.

Project Management Institute (2008). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.

Sauer, C., Gemino, A., & Reich, B. H. (2007). The impact of size and volatility on IT project performance. Communications of the ACM, 50(11), 79–84.

Reich, B. H., Sauer, C., & Wee, S. Y. (2008). Innovative practices for IT projects. Information Systems Management, 25(3), 266–272.

Saynisch, M. (2010). Beyond frontiers of traditional project management: An approach to evolutionary, self–organizational principles and the complexity theory—Results of the research program. Project Management Journal, 41(2), 21–37.

Saynisch, M. (2010a). Mastering complexity and changes in projects, economy, and society via Project Management Second Order (PM-2). Project Management Journal, 41(5), 4–20.

Shenhar, A. J. (1998). From theory to practice: Toward a typology of project–management styles. IEEE Transactions on Engineering Management, 45(1), 33–48.

Shenhar, A. J. (1999). Strategic project management: The new framework. In D. F. Kocaoglu & T. R. Anderson (Eds.) Technology and innovation management (pp 382–386). Portland, OR: Portland State University.

Shenhar, A. J., & Dvir, D. (2007). Reinventing project management: The diamond approach to successful growth and innovation. Boston, MA: Harvard Business Press.

Simon, L. (2006). Managing creative projects: An empirical synthesis of activities. International Journal of Project Management, 24(2), 116–126.

Stepanek, G. (2005). Software project secrets: Why software projects fail. Berkeley, CA: APress.

Tatikonda, M. V., & Rosenthal, S. R. (2000). Technology novelty, project complexity, and product development project execution success: A deeper look at task uncertainty in product innovation. IEEE Transactions on Engineering Management, 47(1), 74–87.

Williams, T. M. (1999). The need for new paradigms for complex projects. International Journal of Project Management, 17(5), 269–273.

Williams, T. (2005). Assessing and moving on from the dominant project management discourse in the light of project overruns. IEEE Transactions on Engineering Management, 52(4), 497–508.

Wysocki, R. K. (2006). Effective software project management. Indianapolis, IN: John Wiley & Sons, Inc.

Wysocki, R. K. (2007). Effective project management—Fourth edition. Indianapolis, IN: John Wiley & Sons, Inc.

Xia, W., & Lee, G. (2005). Complexity of information systems development projects: Conceptualization and measurement development. Journal of Management Information Systems, 22(1), 45–83.

Yang, L., O'Connor, J. T., & Wang, C. (2006). Technology utilization on different sizes of projects and associated impacts on composite project success. International Journal of Project Management, 24(2), 96–105.

Yetton, P., Martin, A., Sharma, R., & Johnston, K. (2000). A model of information systems development project performance. Information Systems Journal, 10(4), 263–289.

©2012 Project Management Institute



Related Content

  • PMI White Paper

    Agile Regulation member content open

    By National Academy of Public Admiistration | PMI The National Academy of Public Administration recently presented the results of a year-long effort to identify the Grand Challenges in Public Administration.

  • PM Network

    The Next Agile Awakening member content open

    By Parsi, Novid, During the all-hands, anything-goes disruption of the global pandemic, agile has been both a reinforcement and a revelation.

  • PM Network

    The Certainty of Uncertainty member content open

    By Fewell, Jesse, As much as we yearn for a pre-pandemic return, it's naive to think the old ways of work will ever return—even for agile.

  • PM Network

    La certeza de la incertidumbre member content open

    By Fewell, Jesse Por mucho que anhelemos un regreso antes de la pandemia, es ingenuo pensar que las viejas formas de trabajo volverán alguna vez, incluso para lo ágil.

  • PM Network

    El próximo despertar ágil member content open

    By Parsi, Novid Durante la interrupción de todo vale de la pandemia global, Agile ha sido tanto un refuerzo como una revelación.