Measuring the complexity of software projects Panos Fitsilis Project Management Department, TEI Larissa, 41110 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.
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 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. 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-to-market 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 complexity
and
Technological
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 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, planning, 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 project-related 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.
4. Sources of project 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 Project Integration Management
SOURCES OF COMPLEXITY (TYPE OF COMPLEXITY) The complexity of the planning process (CoFact) Executing organization immaturity (CoFact) Software requirements volatility (CoFact) Clarity of project objectives and management commitment (CoFaith) Software Development Methodology (CoFaith) Project Novelty (CoFaith)
Project Environment (CoFaith) Project Scope Management
Software Size (CoFact) Software Structure and architecture (CoFact)
Project Time Management
Project schedule (CoFact)
Project schedule difficulty (CoFact) Project Cost Management
Project budget structure (CoFact)
Project Quality Management Project Human Resource Management
Quality planning (CoFact) Size and structure of the team (CoFact)
Personnel expertise and quality (CoFaith)
Project Communication Management
Project Risk Management
Reporting requirements (CoFact) Information flow (CoInteraction) Actors involved in the project (CoInteraction) Risk identification, quantification and response planning (CoFact)
INDICATIVE METRICS - Number of project management processes employed - Level of maturity (e.g. CMM level) - Number of change requests - Number of stated objectives - Financial resources committed - Number of phases - Level of rigidity/agility - Number of similar software projects within organization - Number of similar software projects in the literature - Legislation and regulations - Market and competition - Metrics such as FPA, UCP - Number of deliverables - WBS levels - Number of components, modules - Number of third party components used - Number of different technologies used within project - Project duration - Number of activities - Number of organizations (units) involved - Number of different resources needed - Number of dependencies between activities - Number of activity constraints - Budget size - Number of different budget lines - Level of accuracy - Number of quality metrics employed - Number of quality reviews - Team size - Variety of different skills needed - Personnel availability and mobility - Geographical distribution - Personnel technological experience - Personnel problem domain experience - Personnel process familiarity - Reporting frequency - Number of different reports - Different number of communication flows - Number of planned meeting - Number of different stakeholders - Number of risks identified - Number of risks quantitative analyzed - Number of risks where a mitigation plan is
PMBOK SUBJECT AREA Project Procurement management
SOURCES OF COMPLEXITY (TYPE OF COMPLEXITY)
INDICATIVE METRICS
Procurement planning (CoFact)
-
Procurement execution (CoFaith) Procurement execution (CoInteraction)
5. Conclusions
[9] [10]
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.
[11]
[12]
[13]
[14]
[15]
[16]
[17]
6. References [18] [1]
[2]
[3]
[4]
[5] [6]
[7]
[8]
The Standish Group, “Extreme Chaos,” The Standish Group 2001; [Online]. Available http://www.standishgroup.com/ sample_research. [Accessed: Dec. 19, 2008]. R.N. Charette, “Software Hall of Shame,” IEEE Spectrum, September 2005. [Online]. Available http://www.spectrum.ieee.org/sep05/1685. [Accessed: Dec. 19, 2008]. L. Laird, and M. Brennan, Software Measurement and Estimation. A practical approach, John Wiley and Sons, 2006. W.A. Florac, R.E. Park, and D. Carleton, Practical Software Measurement: Measuring for Process Management and Improvement, Software Engineering Institute (SEI), Pittsburgh, CMU/SEI-97-HB-003, 1997. H.A. Simon, “The architecture of complexity,” Proceedings of the American Philosophical Society, 1962. Project Management Institute, “A Guide to the Project Management Body of Knowledge, Fourth Ed.,” Project Management Institute, ANSI/PMI Standard 99-001-2008. J. Geraldi, “Patterns of complexity: The Thermometer of complexity”, Project Perspectives, IPMA, 2008, vol. 29, pp. 4-9. L.A. Vidal and F. Marle, “Understanding project complexity: implications on project management”, Kybernetes, vol. 37 No. 8, 2008, pp. 1094-1110.
[19]
[20] [21]
[22]
available Number of procurement orders Value of procured goods and/or services Number of new external contractors Maturity and fidelity of external contractors Number of different organizations involved
Cambridge Advanced Learner’s Dictionary. [Online] Available http://dictionary.cambridge.org R. Park. “Software size measurement: a framework for counting source statements”, CMU/SEI-92-TR-020. [Online] Available http://www.sei.cmu.edu/pub/documents/92.reports/ pdf/tr20.92.pdf [Accessed: Dec. 19, 2008]. D. Gamus and D. Herron, Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley, 2000. G. Karner, Metrics for Objectory. Diploma thesis, University of Linkoping, Sweden. No. LiTH-IDA-Ex-9344:21. December 1993. B. Boehm, C. Abts, A.W. Brown, S. Chulani, B.K. Clark, E. Horowitz, R. Madachy, D.J. Reifer, and B. Steece, Software Cost Estimation with COCOMOII, Prentice Hall, Englewood Cliffs, NJ, 2000. A. Griffin, “The effect of project and process characteristics on product development cycle time,” Journal of Marketing Research., vol. 34, pp. 24–35, 1997. D. Baccarini, “The concept of project complexity--a review,” International Journal of Project Management, vol. 14, issue 4, pp. 201-204, 1996. A. Camci, T. Kotnour, “Technology Complexity in Projects: Does Classical Project Management Work?” PICMET 2006 Proceedings, pp. 2181-2186, Turkey, 2006. K. Dooley, Organizational Complexity, International Encyclopedia of Business and Management, M. Warner (ed.), London: Thompson Learning, p. 5013-5022, 2002. J. Geraldi, and G. Adlbrecht,, "On Faith, Fact, and Interaction n Projects," Project Management Journal, vol. 38, no. 1, pp. 32-43, 2007. J. Geraldi, “The balance between order and chaos in multiproject firms: A conceptual model,” International Journal of Project Management, vol 26, pp. 348-356, 2008. Williams, T. 2002, Modeling Complex Projects, Chichester.Wiley. SJ. Whitt, and H. Maylor, “And then came Complex Project Management (revised), The Proceedings of 21st IPMA World Congress on Project Management, 2007. K. Richardson, A. Tait, J. Roos, and M.R. Lissack, “The Coherent Management of Complex Project and the Potential Role of Group Decision Support Systems,” in Managing Organizational Complexity: Philosophy, Theory and Application, Vol., K. Richardson, Ed., Information Age Publishing, 2005, pp. 433-472.
