Journal of Software Engineering and Applications
Vol.08 No.10(2015), Article ID:60585,7 pages
10.4236/jsea.2015.810052

Software Project’s Complexity Measurement: A Case Study

Panos Fitsilis*, Vyron Damasiotis

Technological Educational Institute of Thessaly, Larissa, Greece

Email: *fitsilis@teilar.gr, bdama@teilar.gr

Copyright © 2015 by authors and Scientific Research Publishing Inc.

This work is licensed under the Creative Commons Attribution International License (CC BY).

http://creativecommons.org/licenses/by/4.0/

Received 10 September 2015; accepted 23 October 2015; published 26 October 2015

ABSTRACT

Project management is a well understood management method, widely adopted today, in order to give predictable results to complex problems. However, quite often projects fail to satisfy their initial objectives. This is why studying the factors that affect the complexity of projects is quite important. In this paper, we will present the complexity factors that are related to project time, cost and quality management and then we will apply them to a number of selected projects, in order to compare the acquired results. The projects have been chosen in a way that results can be easily compared.

Keywords:

Software Project Management, Project Complexity, AHP

1. Introduction

Research studies have shown that very often projects fail to meet their requirements in terms of quality, time and cost restrictions. It is widely accepted that amongst the main reasons for these failures is the increased complexity of modern projects due to their special characteristics. There is a lack of consensus in defining what project complexity is. This fact resulted in the development of different approaches for classifying project management complexity. However many researchers agree that complexity is “consisting of many varied and interrelated parts” [1] .

Software projects are among the most complex ones. Many studies on various types of software project have proven that their outcomes are far from the complete fulfilment of the initial requirements [2] . Most studies measure complexity either by measuring the software project product based on its attributes such as size, quality, reliability or the characteristics of software project process using attributes such as performance, stability, improvement [3] . As such the need to establish a systematic way to evaluate the software project complexity is important.

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 com- plexity is used as a replacement for project size, or alternatively to project difficulty; or it is perplexed with project’s product complexity [4] . In most cases, the complexity of projects is measured either by measuring the attributes of project products or by measuring the characteristics of project processes. In our approach, it is suggested that the complexity of projects should be studied by applying structured project management techniques [5] .

The purpose of this paper is to study how factors are contributing to the complexity of projects. These factors are related with project time, cost and quality management and they have been identified in [6] [7] . Based on these factors a complexity model is built. Subsequently, this model has been validated with a number of projects. Finally, the results and the future work are presented.

2. Background

Complexity is part of our environment and appears in different domains. Many scientific fields have dealt with complex systems and have attempted to define the term complexity according to their domain. This implies that there is a different definition of complexity in computational theory, in information theory, in business, in software engineering etc. and many times there are different definitions inside the same domain. Schlidwein and Ison [8] states that are two major approaches of complexity. The first one describes the complexity as a property of a system, called descriptive complexity. The other approach describes complexity as perceived complexity and translates it as the subjective complexity that someone experiences through the interaction with the system.

This lack of consensus in defining what project complexity is has resulted in a variety of approaches on classifying project management complexity. One of the first researches that deal with the concept of complexity was Baccarini [9] . He considers complexity as something “consisting of many varied and interrelated parts” and operationalized them in terms of “differentiation” the number of varied elements (e.g. tasks, components) and “interdependency” the degree of interrelatedness between these elements. Finally he describes four types of complexity: 1) organizational complexity by differentiation and 2) organizational complexity by interdependency 3) technological complexity by differentiation and 4) technological complexity by interdependency.

Extending the work of Baccarinni, Williams [10] added the dimensions of uncertainty in projects and the multi-objectivity and multiplicity of stakeholders. The definition of project complexity according to Williams is divided in structural complexity sourcing from number and interdependence of elements and uncertainty sourcing from uncertainty in goals and methods.

Geraldi and Adlbrecht [11] and Geraldi [12] [13] based on structural complexity and uncertainty defined three types of complexity, the complexity of faith (CoFaith), Complexity of Fact (CoFact) and Complexity of Interaction (CoInt).

Maylor et al. [14] focused on perceived managerial complexity under two dimensions structural and dynamic and identified five aspects of complexity. They defined a complexity model that is based on Mission, Organization, Delivery, Stakeholders and Team (MODeST).

According to our previous work [6] in order to assess complexity we need a holistic framework that will take into account all areas of PM as they are defined in PMBOK [15] . This framework should define factors that affect complexity and metrics associated with each factor. Subsequently, these metrics will be evaluated by experts for their contribution in total project complexity and as such a model shall be developed. It should be noted that the developed model is not unique, neither the same for all projects. Simply, each developed model represents the consensus of each group of experts, of each company, etc. The final outcome is a parametric model that gives a quantitative indication of the expected complexity of the project (Figure 1). The numerical

Figure 1. Project evaluation according to their complexity.

representation of the project complexity makes easier the relative comparison of projects complexity as well as the complexity of the project itself. In addition, this approach allows the implementation of thresholds in project complexity that will allow the projects classification into categories according to the level of complexity. Also relative comparison of complexity will allow the comparison of different management and implementation approaches of projects and selection of the one with the lowest complexity. The main problem of this approach was, that building such models requires laborious work since the number of subject areas as they have been defined in PMBOK are ten (www.pmi.org), resulting to hundreds of factors and metrics.

The same problem has been faced by other researchers that attempted to limit the number of complexity categories and dimensions (factors) to a minimum number. For example, Vidal et al. [4] , studied project complexity under the organizational and technological dimensions and identified four aspects for studying project complexity: project size, project variety, project interdependence and project context. For this reason, in our model it was decided to limit the number of subject areas and instead of using PMBOK’s ten subject areas, to use three subject areas namely: time, cost and quality [15] . This constitutes the well know project management iron triangle that according to all scholars and practitioners defined the most influential factors for project success. A number of potential complexity factors have been identified as a result of an extensive literature review.

3. Presentation of the Case Study

After adopting the proposed factors that were found most frequently in the literature review, this initial set of factors was evaluated using the multi-criteria decision-making method, Analytical Hierarchy Process (AHP) [16] for defining the relative weight of each factor. The application of AHP method was done by using online AHP system that facilitated the whole process (http://bpmsg.com/academic/ahp.php ).

The primary objective of AHP is to classify a number of alternatives (e.g., a set of quality determinants) by considering a given set of qualitative and/or quantitative criteria, according to pair wise comparisons/judgments provided by the decision makers. AHP results in a hierarchical levelling of the quality determinants, where the upper hierarchy level is the goal of the decision process, the next level defines the selection criteria which can be further subdivided into sub criteria at lower hierarchy levels and, finally, the bottom level presents the alternative decisions to be evaluated.

The main advantages of applying the AHP method are: it is capable to provide a hierarchical decomposition of a decision problem that helps in better understanding of the overall decision making process, it handles both quantitative and qualitative criteria, it is based on relative, pair wise comparisons of all decision elements; instead of arbitrarily defining a percentage score and a weight for each decision element, AHP allows the decision maker to focus on the comparison of two criteria/alternatives, at a time, thus it decreases the possibility of defining ratings based only on personal perceptions of the evaluators or other external influences.

Three are the basic concepts that AHP is based on (see Figure 2):

Figure 2. AHP structure.

・ Complexity Analysis: A hierarchical tree is created with criteria, sub-criteria and alternative solutions as the leaves.

・ Calculation/Estimation is executed in every tree level based on a 1 to 9 scale in order to measure priorities. More specifically, a pair wise comparison takes place in every tree level with regards to the parent node. The goal node in the hierarchical tree exists only to highlight the top-down analysis of the methodology.

・ Synthesis with ultimate goal to extract the final priorities of the alternatives.

As it was mentioned, AHP is a method that orders the priorities in a given situation, incorporating the element of subjectivity and intuition so that a final decision can be reached by making decisions for part-issues in a consistent way and gradually move up levels to deal with the given situation having a clear view of what it entails. In AHP, alternatives are paired and decisions makers are called to note their preference between the two alternatives for a variety of issues (see Figure 2), in a scale of 1-9, assigning relative levels of priority to these judgments as they go along. Each element in compared to all other elements, using the scale presented, for defining their relative importance. These judgments are quantified and calculated so that when synthesized, they reveal the best alternative. AHP is relatively simple and logical and given that a certain consistency in the part-deci- sions is maintained, AHP can help decision makers deal with complicated issues where often not only tangible but also intangible parameters affect their decision. It should be noted briefly at this point that AHP is as effective as its design in each individual case and that analysts should exercise care and precision in capturing the true sub-elements and requirements of the case in question.

A small number of project managers have evaluated these factors and the ranking produced is presented in Table 1.

Table 1. Complexity factors.

The above factors lead to the decision tree presented in Figure 3. We have done the assumption that all top level factors: cost, time and quality contribute to the complexity with the same weight, 33.33% since all factors are considered equivalent for project success.

In order to evaluate the above model we have defined three projects. The reasons that we have decided to define these projects and not to evaluate real projects was simply for better demonstrating the validity of the proposed model, at least at this level. The characteristics of these projects are the following:

Project A: It is a project offering IT services to third parties. As such it is a long duration project, with many of diverse type of activities, having many dependencies since it has many stakeholders and large number of deliverables. However, this is a well-planned project and therefore the number of critical activated is quite limited. Since this is a service project we might have additional service requests leading usually to budget increase. Project A is financed by a number of companies that are sharing the same building infrastructure. A QA department is used to ensure the quality of the services delivered and since it is a long duration project all procedures followed are documented in detail.

Project B: Project B is totally different case than project A, since this is an IT services consultancy projects. This is a short duration (three months) with few tasks. However, the required resources are rare since this project requires high-end technical profiles. Project B’s budget may vary significantly, in relation to the findings of the preliminary problem analysis. If a quick solution can be found, project B will finish successfully and quickly. However, if technical problems still persist it might be needed to be extended in duration, considerably. Project B is financed by a single source, the company that ordered the consultancy services and since project B was the result of urgent request due to technical problems, the project was not planned and it started without any actual planning. Quality procedures have not been foreseen.

Project C: It is a software development project requiring complex software development. The duration of the project is average (one year), with average number of dependencies between the activities and average number of deliverables. Project C is a fixed price project and it is foreseen a regular and constant cash flow. Project C is financed by a single source, a public organization that is solely funded by the State. Since the project is funded by a public organization, there are bureaucratic procedures involved in all project management activities. All quality procedures are well documented, known and the quality assurance positions are fully staffed.

Since, all projects are run from the same company we consider that factors related to experience and tools are influencing with the same weight the complexity of all three projects.

In Figure 4, we present the evaluation of the time related factors, according to a small group of experts. As we can observe according to project time management complexity, the most complex project is A, that it is really a large project (see project profile above), followed by project B that is a project starving for resources. According to the classification of the time factors, the factor “Lack/Insufficient resources, especially rare” influences heavily Project B. The result is that project B is perceived as more complex that project C.

The same analysis (pairwise comparisons) has been done for cost (see Figure 5) and quality (see Figure 6) factors. In relation, to the cost management project B is the most complex, since the project started without any initial planning and the budget may change considerably. The less complex is project C that is funded by a public organisation, the funding is secured and it is a fixed price contract. Similarly, if we evaluate the quality complexity factors we see that the fact that project B does not apply any quality procedure makes this project the most difficult to handle. The other two projects according to their profile exhibit similar complexity.

The final step is to combine, time, cost and quality complexity scores into one score. As we have already explained we make the assumption that all these three factors have equal weight, since their contribution to project success is valued equally The end results are presented in Table 2 which demonstrates that even if project B is considered smaller, with less tasks, etc. it has been evaluated as more complex.

The above presented results give a logical and valid representation of project complexity. However, in order, for this model to be used in reality, it has to be validated with real projects and possibly to make adaptions to the influencing factors and on its weights.

4. 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.

We have presented a simple and straight forward model for the measurement of project complexity. Project complexity is a useful measure on how much attention, we should put on a project taking into account not only the size but also the budget value of the project. It may be used together with other metrics for lowering the risk undertaken in various projects. Of course, a lot of work remains to be done.

Figure 3. Complexity decision tree.

Figure 4. Evaluation of time related complexity factors.

Figure 5. Evaluation of cost related complexity factors.

Figure 6. Evaluation of quality related complexity factors.

Table 2. Evaluating complexity.

Firstly, all presented elements have to be further analysed in order to produce a model that is able to calculate robustly project complexity by combining factual, dynamic and interaction elements. 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. Finally, we need to validate the model, in order to see if measured and perceived complexity is similar.

Acknowledgements

This research has been co-financed by the European Union (European Social Fund―ESF) and Greek national funds through the Operational Program “Education and Lifelong Learning” of the National Strategic Reference Framework (NSRF)―Research Funding Program: ARCHIMEDES III. Investing in knowledge society through the European Social Fund.

Cite this paper

PanosFitsilis,VyronDamasiotis, (2015) Software Project’s Complexity Measurement: A Case Study. Journal of Software Engineering and Applications,08,549-556. doi: 10.4236/jsea.2015.810052

References

  1. 1. Bertelsen, S. (2003) Complexity-Construction in a New Perspective. IGLC-11, Blacksburg, Virginia.

  2. 2. The Standish Group (2009) CHAOS Summary 2009. The 10 Laws of CHAOS, The Standish Group International.
    https://www.classes.cs.uchicago.edu/archive/2014/fall/512101/required.reading/Standish.Group.Chao s.2009.pdf

  3. 3. Laird, L. and Brennan, M. (2006) Software Measurement and Estimation. A Practical Approach. John Wiley and Sons, New York.
    http://dx.doi.org/10.1002/0471792535

  4. 4. Vidal, L.-A. and Marle, F. (2008) Understanding Project Complexity: Implications on Project Management. Kybernetes, 37, 1094-1110.
    http://dx.doi.org/10.1108/03684920810884928

  5. 5. Damasiotis, V. and Fitsilis, P. (2015) Assessing Software Project Management Complexity: PMCAT Tool. New Trends in Networking, Computing, E-Learning, Systems Sciences, and Engineering. Springer International Publishing, 235-242.
    http://dx.doi.org/10.1007/978-3-319-06764-3_30

  6. 6. Damasiotis, V., O’Kane, J.F. and Panos, F. (2014) Scope Management Complexity in Software Projects: An Approach to Evaluate It. BAM 2014, British Academy of Management, UK.

  7. 7. Georgosopoulou, A. (2015) Measuring Construction Project Complexity. TEI Thessaly, School of Business and Economics.

  8. 8. Schlindwein, S.L. and Ison, R. (2004) Human Knowing and Perceived Complexity: Implications for Systems Practice. Emergence: Complexity and Organization, 6, 27-32.

  9. 9. Baccarini, D. (1996) The Concept of Project Complexity—A Review. International Journal of Project Management, 14, 201-204.
    http://dx.doi.org/10.1016/0263-7863(95)00093-3

  10. 10. Williams, T.M. (1999) The Need for New Paradigms for Complex Projects. International Journal of Project Management, 17, 269-273.
    http://dx.doi.org/10.1016/S0263-7863(98)00047-7

  11. 11. Geraldi, J. and Adlbrecht, G. (2006) On Faith, Fact, and Interaction in Projects. Project Management Journal, 38, 32-43.

  12. 12. Geraldi, J. (2008) Patterns of Complexity: The Thermometer of Complexity. Project Perspectives, IPMA, 29, 4-9.

  13. 13. Geraldi, J. (2008) The Balance between Order and Chaos in Multi-Project Firms: A Conceptual Model. International Journal of Project Management, 26, 348-356.
    http://dx.doi.org/10.1016/j.ijproman.2007.08.013

  14. 14. Maylor, H., Vidgen, R. and Carver, S. (2008) Managerial Complexity in Project Based Operations: A Grounded Model and Its Implications for Practice. Project Management Journal, 39, S15-S26.
    http://dx.doi.org/10.1002/pmj.20057

  15. 15. Rose, K.H. (2013) A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition. Project Management Journal, 44, e1.

  16. 16. Saaty, T.L. (1988) What Is the Analytic Hierarchy Process? Springer, Berlin Heidelberg.
    http://dx.doi.org/10.1007/978-3-642-83555-1_5

NOTES

*Corresponding author.