Classification of Software Projects’ Complexity P. Fitsilis1 , A. Kameas2, L. Anthopoulos1 1
Technological Education Institute of Larissa,
41110 Greece. {fitsilis, anthopoulos}@teilar.gr 2
Hellenic Open University,
23 Sahtouri str., 26222 Patras, Greece.
[email protected]
Abstract: Software project complexity is a subject that has not received detailed attention. The purpose of this paper is to present a systematic way for studying and modeling software project complexity. The proposed model is based on the widely known and accepted Project Management Body of Knowledge and it uses a typology for modeling complexity based on complexity of faith, fact and interaction. Keywords: Software project management, software project complexity
1. Introduction Software projects are complex endeavors and in many cases their outcome is far from being certain. This has been proven by many studies and on various project types. As a result, the track record of software engineering industry is rather disappointing [1, 2]. This implies, at least, that software projects are complex undertakings. Traditionally, complexity in software projects is measured implicitly: either by measuring the software project product, or by measuring characteristics of the software process. A large number of metrics have been described in the bibliography for measuring different characteristics of software and software projects, such as size, complexity, reliability, and quality [3]. Respectively, for software processes five are the perspectives that are central to measurement: performance, stability, compliance, capability and improvement [4]. These approaches in measuring complexity are not sufficient since “in complex systems the whole is more than the sum of parts” and “given the properties of the parts and the laws of interaction, it is not trivial to infer the properties of the
2
P. Fitsilis, A. Kameas, L. Anthopoulos
whole” [5]. This directs us to the observations that complexity can only be measured holistically. In this paper, we present a holistic model for measuring the complexity of software projects. The model is build by combining Project Management Body of Knowledge (PMBOK) [6] with Patterns of Complexity [7]. PMBOK defines nine project management knowledge areas which are: Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management and Project Procurement Management. PMBOK exhibits a number of characteristics that make its usage attractive for measuring the software project complexity: it is well known, it combines knowledge required with necessary processes, and it is analytical. Despite the advantages PBMOK is not sufficient for measuring project complexity since complexity appears in many different forms. According to Geraldi’s [7] typology of complexity, “complexity of faith” is due to uncertainty, “complexity of fact” refers to the amount of interdependent information and “complexity of interaction” is present in interfaces between systems or locations of complexity. The model is build by defining for each PMBOK knowledge area and for each complexity category a set of metrics which allows the measurement of project complexity in a robust and multi-facet manner that takes into account project management knowledge, processes and patterns of complexity.
2. Project complexity and patterns of complexity Project complexity is a common concept recognized in a number of different ways. It is given a number of different interpretations based on the reference context or on each individual’s experience. In many cases project complexity is used as a replacement for project size, or alternatively to project difficulty. Further, in other cases project complexity is perplexed with project’s product complexity. Definitely there is a lack of consensus on what project complexity really is [8]. The dictionary definition of complex is something involving of different but related parts, or difficult to understand [9].
2.1 Complexity and size Project size is an important characteristic that in a large extend can capture the complexity of a project. Size is one of the most important attributes of software and, in most cases, it is directly related with the effort required, the productivity of the team, the required quality, etc.
Classification of software projects complexity
3
Commonly used software sizing methodologies are counting the Lines Of Code (LOC) of the source code [10], Function Point Analysis (FPA) [11], Use Case Points (UCP) [12], COCOMO II [13], etc. Even though, complexity is present as one of the systems’ characteristics examined, for estimating the size, in most of the above methodologies e.g. “Complex Processing” in FPA, “Complex Internal Processing” in UCP, project size alone cannot be used for measuring the complexity of a project. This applies since a large but well structured software project with relaxed cost and time constraints can be much less complex in comparison with a relatively small in size project which has a highly integrated product design and limited budget and/or time-tomarket objectives.
2.2 Product versus project complexity The term “product complexity” and “project complexity” in many cases is used interchangeably [14]. Baccarini [15] regards product complexity as a subcategory of technological complexity, which covers complexities related to products and processes. Usually, when we are measuring the complexity of the software product, our objective is to predict and to understand what causes increased defects and lower productivity. Therefore more development effort is required and as a result the software project is more complex. Software complexity is demonstrated in three different forms: structural, conceptual and computational. Structural complexity looks at the design and structure of the software itself, conceptual complexity refers to difficulty in understanding the system/requirements and/or code itself, the novelty/newness of the software product and finally computational complexity refers to the complexity of the computation being performed [3, 16].
2.3 Organizational and Technological complexity Baccarini [15] defined two facets of project complexity: the organizational facet and the technological facet. Organizational complexity is defined as the amount of differentiation that exists within different elements constituting the organization [17, 22]. The differentiation has two dimensions: vertical (depth of organization) or horizontal (organizational structure, task structure). One important characteristic of organizational complexity especially in projects is the ability or inability of organizational elements to connect and to interact The second facet of complexity, as defined by Baccarini, is technical complexity. More specifically, he defines technological complexity by differentiation, which
4
P. Fitsilis, A. Kameas, L. Anthopoulos
refers to the variety or diversity of some aspect of a task, and technological complexity by interdependency, between tasks, within a network of tasks; between teams, etc.
2.4 Patterns of complexity Geraldi [7, 18, 19] and Williams [20] defined three types of complexity: Complexity of Faith (CoFaith): It is synonym to uncertainty and it is present since projects are creating something unique, or solving new problems. Usually, at the beginning of a project, we are dealing with uncertainty (on resources, effort required, etc). However, the uncertainty is decreasing as the project progress and as a result CoFaith is transformed to Complexity of Fact. CoFaith cannot be measured objectively. Even when there is a quantitative way to measure CoFaith this is based on subjective opinions. Complexity of Fact (CoFact): It is similar to structural complexity and considers complexity as an intrinsic property of the software system. The most important problem in measuring the CoFact is that it relates with a very large number of interdependent information. An attempt to exhaustively analyze and measure all the contributing factors will fail and therefore we should always keep a holistic view on the project complexity measurement. Complexity of Interaction (CoInteraction): It is present in interfaces between systems, locations, humans and it is characterized by transparency, multiplicity of reference and empathy.
3. Project Management Body of Knowledge As it was mentioned before, Project Management Body of Knowledge (PMBOK) [6] is defined in terms of process groups and knowledge areas. In this study, we will focus on the knowledge areas, since these areas are offering a more precise idea of what is project management about and at the same time they give the overall picture on how to measure project complexity. The knowledge areas defined in PMBOK are the following: Project Integration Management describes the processes and activities needed to identify, define, combine, unify and coordinate processes and project management activities. The main objective during the initial phase of the project is to define the project charter and to develop the project plan, while at latter phases the emphasis is shifted to monitoring and controlling the project plan. Obviously, this initial phase exhibits increased uncertainty and it inherently complex. A large part of the project integration management subject area is the change management. Change management is the process of requesting, determining attainability, plan-
Classification of software projects complexity
5
ning, implementing and evaluation of changes to a software system. Large number of changes, implies increase system volatility and complexity (i.e. through changes the structure of a system becomes more complex). Project Scope Management. It encapsulates processes for ensuring that project work is defined, verified and controlled. Due to the nature of software projects, where the project product is intangible scope management presents increased difficulty and it adds complexity to the project. Therefore, the problem of managing software requirements is listed as one of the most difficult in the software life cycle. Project Time Management, which describes the processes concerning the timely completion of the project. It includes the definition and sequencing of the activities, estimation of their duration, estimation of the resources needed and development of project schedule. Factors such as number of activities, difficulty of activities, number of resources involved, tidiness of schedule etc. are all influencing the complexity of the project. Project Cost Management that includes processes involved in estimating budgeting and controlling cost. Project Quality Management describes the processes involved in assuring that the project will satisfy the objectives for which it was undertaken. Quality objectives set during the quality planning phases can introduce complexities to software projects. Project Human Resource Management includes all necessary processes for organizing, managing and leading the project team. Organization complexity is defined in the literature as one of the most important sources of project complexity. Further, factors such as team size, number of different professions required can contribute significantly to project complexity. Project Communications Management. It describes the processes concerning the communication mechanisms of the project, and relate to the timely and appropriate generation, collection, dissemination, storage and ultimate disposition of project information. It is related directly with organizational complexity and it is affected by the number of project stakeholders. Project Risk Management describes the processes concerned with projectrelated risk management. Risk is a future, uncertain event that if it occurs has a negative effect on scope, time, cost or quality. Therefore, the complexity in risk management is related with the process for handling the risk rather with the risk itself. Project Procurement Management includes all processes that deal with acquiring products and services needed from third parties for completing the project. The number, size, novelty of the procured goods or services can influence the complexity of the project.
6
P. Fitsilis, A. Kameas, L. Anthopoulos
4. Sources of complexity The first step for developing a model for systematically measuring complexity is defining a set of software project characteristics that are the sources of complexity. An exhaustive list with sources of complexity would be enormously large, and at the end of no practical use since it would be proven difficult to measure everything. Further, it would be impossible to agree on the exact scope of each complexity source, neither on the definition. Literature provides significant evidence on the validity of the above arguments, since numerous authors are proposing different typologies, characteristics, attributes etc. Therefore, it is necessary to use a well established and widely accepted framework for classifying the sources of complexity and subsequently for studying project complexity. This can be achieved by combing, a project management framework such as PMBOK, with a complexity typology, such as “patterns of complexity”. Table 1 presents a summary of the identified source of complexity along with indicative metrics that could be used. Table 1. Taxonomy of complexity
PMBOK Subject Area
Sources of Complexity (Type of Complexity)
Indicative Metrics
Project Integration Management
The complexity of the planning process (CoFact)
Number of project management processes employed
Executing organization immaturity (CoFact)
Level of maturity (e.g. CMM level)
Software requirements volatility (CoFact)
Number of change requests
Clarity of project objectives and management commitment (CoFaith)
Number of stated objectives
Software Development Methodology (CoFaith)
Number of phases
Project Novelty (CoFaith)
Number of similar software projects within organization
Financial resources committed
Level of rigidity/agility
Number of similar software projects in the literature Project Environment (CoFaith)
Legislation and regulations Market and competition
Project Scope Management
Software Size (CoFact)
Metrics such as FPA, UCP
Software Structure and architecture (CoFact)
WBS levels
Number of deliverables Number of components, modules
Classification of software projects complexity
PMBOK Subject Area
Sources of Complexity (Type of Complexity)
Indicative Metrics Number of third party components used Number of different technologies used within project
Project Time Management
Project schedule (CoFact)
Project duration Number of activities Number of organizations (units) involved Number of different resources needed
Project schedule difficulty (CoFact)
Number of dependencies between activities Number of activity constraints
Project Cost Management
Project budget structure (CoFact)
Budget size Number of different budget lines Level of accuracy
Project Quality Management
Quality planning (CoFact)
Number of quality metrics employed
Project Human Resource Management
Size and structure of the team (CoFact)
Team size
Number of quality reviews Variety of different skills needed Personnel availability and mobility Geographical distribution Personnel expertise and quality (CoFaith)
Personnel technological experience Personnel problem domain experience Personnel process familiarity
Project Communication Management
Reporting requirements (CoFact)
Reporting frequency
Information flow (CoInteraction)
Different number of communication flows
Number of different reports
Number of planned meeting
Project Risk Management
Actors involved in the project (CoInteraction)
Number of different stakeholders
Risk identification, quantification and response planning (CoFact)
Number of risks identified Number of risks quantitative analyzed Number of risks where a mitigation plan is available
7
8
P. Fitsilis, A. Kameas, L. Anthopoulos
PMBOK Subject Area
Sources of Complexity (Type of Complexity)
Project Procurement management
Procurement planning (CoFact)
Indicative Metrics Number of procurement orders Value of procured goods and/or services
Procurement execution (CoFaith)
Number of new external contractors Maturity and fidelity of external contractors
Procurement execution (CoInteraction)
Number of different organizations involved
5. A case study The project used for the case study is a typical ICT project since it combines custom software development, procurement of Commercial Off The Shelf (COTS) software and hardware, installation and operation of a electronic service. The system under evaluation is an Electronic Proposals Submission System that will facilitate the process of electronic proposal submission for the purposes of a Public Research Agency. More specifically the project includes the following tasks: the development of a browser-independent web-based Proposals Submission System enabling research project proposals to be constructed and submitted electronically. the development of a system for preparing a proposal identical to those produced on the system via a stand-alone application. In order to evaluate the complexity of the above described project we will follow a qualitative approach that takes into account the complexity sources identified in table 1. We will evaluate each subject area using a likert scale from 1 to 5, where 1 represents low contribution to project complexity and 5 represents significant contribution to complexity. Further, we make the assumption that all subject areas contribute equally to the complexity of the project, in our case 11.11%. However, this assumption can be easily changed with the application of a multicriteria decision making (MCDM) method, such as Analytical Hierarchical Process (AHP). The AHP method was introduced by Saaty [23] and its primary objective is to classify a number of alternatives (e.g., a set of candidate software metrics) by considering a given set of qualitative and/or quantitative criteria, according to pairwise comparisons/judgments provided by the decision makers. AHP results in a hierarchical levelling of the measurement criteria, where the upper hierarchy level is project management subject areas, the next level defines a set of complexity metrics, which can be further subdivided into subcriteria at lower hierarchy levels. In our example, as it was mentioned previously, we have a simple scoring model with equal weights per subject area.
Classification of software projects complexity
9
A key prerequisite for the calculation of the complexity is the definition of the scale that will be used for each metric. For example, the metric “Number of change requests” should be evaluated according to Table 2. Table 2. Example of metric’s scale Complexity Metric Number of change requests
Very Low (1) 1% requirements changes
Low (2) 3% requirement changes
Moderate (3) 5% requirements changes
High (4) 10% requirements changes
Very High (5) >10%
Table 3. Calculation of complexity in three subject areas (sample)
Subject Area
Indicative Metrics
Justification
Score
Project Integration Management
Number of project management processes employed
Full lifecycle is used. Further, system operation is required
4
Level of maturity (e.g. CMM level)
System is critical for client organization. Therefore, a contractor with high process maturity should be selected
2
Number of change requests
Requirements are stable and well defined
2
Number of stated objectives
Limited number of stated objectives
1
Financial resources committed
Financial resources committed 100%
1
Number of phases
Traditional waterfall lifecycle used
1
Number of similar software projects within organization
Moderate innovation in custom development
3
Number of similar software projects in the literature
Similar implementations exist in the literature
2
Legislation and regulations
Privacy and confidentiality legislation apply
4
Level of rigidity/agility
Project Scope Management
Market and competition
Strong demand from customers
4
Metrics such as FPA, UCP
Moderate number of FP (in comparison with other projects)
3
Number of deliverables
Moderate number of deliverables
3
WBS levels
Three WBS levels
3
10
P. Fitsilis, A. Kameas, L. Anthopoulos
Subject Area
Project Time Management
Indicative Metrics
Justification
Score
Number of components, modules
Small number of modules
2
Number of third party components used
More than 80% is based on COTS software
5
Number of different technologies used within project
Moderate number of different technologies
3
Project duration
Short project development duration
5
Number of activities
Moderate number of activities
3
Number of organizations (units) involved
Large number of units involved
4
Number of different resources needed
Moderate
3
Number of dependencies between activities
Low
2
Number of activity constraints
Moderate
3
Having calculated a score for each contributing complexity factor, we should proceed to the next step which is the calculation of the total project complexity. This calculation is presented in Table 4. Initially, we adjust the total score of the subject area according to the percentage that this subject area is participated in the total score. Subsequently, we take the sum of all partial scores. Table 4. Calculation of total project complexity Subject area
Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communication Management
Contributing % (A)
Unadjusted score (B)
11.11%
24
No of complexity factors (C) 10
11.11%
19
6
63
7,04
11.11%
20
6
67
7,41
11.11%
7
3
47
5,19
11.11%
7
2
70
7,78
11.11%
30
7
86
9,52
11.11%
20
5
80
8,89
Adjusted score (D) 48
Total score (E) 5,33
Classification of software projects complexity
Subject area
Project Risk Management Project Procurement Management
Contributing % (A)
Unadjusted score (B)
11.11%
15
No of complexity factors (C) 3
11.11%
24
5
11
Adjusted score (D) 100
Total score (E) 11,11
96
10,67
In the above table, column A % is given, since the organization assumes that all PM subject areas contribute equally in the project complexity. Column B is calculated by adding the scores of each complexity metric per subject area. Column C gives that total number of metrics used per subject area. Column D adjust the score of column C, using 100 scale. Finally, column E calculates the total score using the contributing % of column A. The total complexity score for this specific project is 72,93, a number that do not convey a lot of information unless we see it comparatively with other projects of the same organization.
6. Conclusions The need to measure complexity is well understood and sufficiently justified. Obviously, software project complexity is an area that needs to be studied further, and in detail. In this paper, we have presented a first set of ideas and a way to systematically measure complexity using the widely and well known PMBOK framework. Of course, a lot of work remains to be done. Firstly, all presented elements have to be further analyzed in order to produce a model that is able to calculate robustly project complexity by combining factual, dynamic and interaction elements. If possibly to produce a thermometer of complexity as it was proposed by Geraldi [7]. Secondly, we need to know, how we can practically measure the evolution of project complexity over project duration and what interventions are necessary for managing and controlling the complexity.
References 1. 2.
The Standish Group (2001) Extreme Chaos,The Standish Group; [Online]. Available http://www.standishgroup.com/ sample_research. [Accessed: Dec. 19, 2008]. Charette, R.N. (2005) Software Hall of Shame, IEEE Spectrum. [Online]. Available http://www.spectrum.ieee.org/sep05/1685. [Accessed: Dec. 19, 2008].
12
P. Fitsilis, A. Kameas, L. Anthopoulos
3.
Laird, L. and Brennan, M. (2006) Software Measurement and Estimation. A practical approach, John Wiley and Sons,. Florac, W.A., Park, R.E. and Carleton, D. (1997) Practical Software Measurement: Measuring for Process Management and Improvement, Software Engineering Institute (SEI), Pittsburgh, CMU/SEI-97-HB-003. Simon, H.A. (1962) The architecture of complexity, Proceedings of the American Philosophical Society. Project Management Institute (2008), A Guide to the Project Management Body of Knowledge, Fourth Ed., Project Management Institute, ANSI/PMI Standard 99-001-2008. Geraldi, J. (2008) Patterns of complexity: The Thermometer of complexity, Project Perspectives, IPMA, vol. 29, pp. 4-9. Vidal, L.A. and Marle, F. (2008) Understanding project complexity: implications on project management, Kybernetes, vol. 37 No. 8, 2008, pp. 1094-1110. Cambridge Advanced Learner’s Dictionary. [Online] Available http://dictionary.cambridge.org Park, R (1992) Software size measurement: a framework for counting source statements. Carnegie Mellor University, CMU/SEI-92-TR-020. [Online] Available http://www.sei.cmu.edu/pub/documents/92.reports/ pdf/tr20.92.pdf [Accessed: Dec. 19, 2008]. Gamus, D. and Herron, D. (2000) Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley. Karner, G. (1993) Metrics for Objectory. Diploma thesis, University of Linkoping, Sweden. No. LiTH-IDA-Ex-9344:21. Boehm, B. Abts, C. Brown, A.W., Chulani, S., Clark, B.K., Horowitz, E., Madachy, R., Reifer, D.J. and Steece, B. (2000) Software Cost Estimation with COCOMOII, Prentice Hall, Englewood Cliffs. Griffin, A. (1997) The effect of project and process characteristics on product development cycle time, Journal of Marketing Research, vol. 34, pp. 24–35. Baccarini, D. (1996) The concept of project complexity--a review, International Journal of Project Management, vol. 14, issue 4, pp. 201-204. Camci, A. and Kotnour, T. (2006) Technology Complexity in Projects: Does Classical Project Management Work?, PICMET 2006 Proceedings, pp. 2181-2186, Turkey. Dooley, K. (2002) Organizational Complexity, International Encyclopedia of Business and Management, M. Warner (ed.), London: Thompson Learning, p. 5013-5022. Geraldi, J. and Adlbrecht, G. (2007) On Faith, Fact, and Interaction n Projects, Project Management Journal, vol. 38, no. 1, pp. 32-43. Geraldi, J. (2008) The balance between order and chaos in multi-project firms: A conceptual model, International Journal of Project Management, vol 26, pp. 348-356. Williams, T. (2002) Modeling Complex Projects, Chichester.-Wiley. Whitt, S.J. and Maylor, H. (2007) And then came Complex Project Management (revised), The Proceedings of 21st IPMA World Congress on Project Management. Richardson, K. , Tait, A., Roos, J. and Lissack, M.R. (2005) The Coherent Management of Complex Project and the Potential Role of Group Decision Support Systems, Managing Organizational Complexity: Philosophy, Theory and Application, Vol., K. Richardson, Ed., Information Age Publishing, pp. 433-472. Saaty, T. L. (1980), The Analytic Hierarchy Process, McGraw Hill, New York.
4.
5. 6. 7. 8. 9. 10.
11. 12. 13.
14. 15. 16. 17. 18. 19. 20. 21. 22.
23.
