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.
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” [
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 [
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 [
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 [
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 [
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 [
Extending the work of Baccarinni, Williams [
Geraldi and Adlbrecht [
Maylor et al. [
According to our previous work [
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. [
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) [
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
・ 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
A small number of project managers have evaluated these factors and the ranking produced is presented in
Time related factors | ||
---|---|---|
Factor | % | Rank |
Large number of deliverables | 26.10% | 1 |
Lack/insufficient resources, especially rare | 23.40% | 2 |
Large number of dependencies between activities | 10.70% | 3 |
Large number of project activities | 8.40% | 4 |
Long project duration | 7.40% | 5 |
Number of critical activities | 7.00% | 6 |
Lack/insufficient time management experience | 6.50% | 7 |
Lack/insufficient time management tools | 4.50% | 8 |
Other time related factors | 3.70% | 9 |
Long duration activities | 2.30% | 10 |
Cost related factors | ||
Factor | % | Rank |
Budget changes and budget cuts | 28.60% | 1 |
Insufficient project planning | 16.30% | 2 |
Financing from various sources | 12.70% | 3 |
Time consuming approval mechanisms | 10.10% | 4 |
Lack/insufficient of costing data for the specific project | 6.60% | 5 |
Project duration and timeframe | 6.50% | 6 |
Other costing factors | 5.30% | 7 |
Team know-how and experience | 5.30% | 8 |
Lack/insufficient of cost management tools | 4.40% | 9 |
Lack/insufficient of historical costing data | 4.20% | 10 |
Quality related factors | ||
Factor | % | Rank |
Lack of QA department | 41.40% | 1 |
Insufficient definition and communication of quality objectives for project | 21.10% | 2 |
Lack/insufficient of responsible personnel on quality procedures | 19.10% | 3 |
Lack/insufficient quality management tools | 12.50% | 4 |
Not well known quality procedures and mechanisms | 5.90% | 5 |
The above factors lead to the decision tree presented in
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
The same analysis (pairwise comparisons) has been done for cost (see
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
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.
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.
Project A | Project B | Project C | |
---|---|---|---|
Time complexity | 0.45 | 0.30 | 0.26 |
Cost complexity | 0.35 | 0.41 | 0.24 |
Quality complexity | 0.17 | 0.67 | 0.17 |
Total project complexity | 0.32 | 0.46 | 0.22 |
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.
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.
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