The design impacts the complexity and in turn the complexity is verified in the execution of the plan. That is why the design often considers the constructive or productive complexity, whether it is a work of urban planning or architecture, or a production of fixed assets. At this level of execution, materials and technologies (construction and production, as they are treated) are key. A good design is generated considering the complexity of the execution and defining the materials and technologies from the beginning. I hope I have collaborated with these simple lines. Best regards,

See http://www.trb.org/Publications/Blurbs/167482.aspx for a report that contains the answers to your question.

As projects have become more and more complex, there has been an increasing concern about the concept of project complexity. An understanding of project complexity and how it might be managed is of significant importance for project managers because of the differences associated with decision-making and goal attainment that are related to complexity. Complexity influences project planning and control; it can hinder the clear identification of goals and objectives, it can affect the selection of an appropriate project organization form, or it can even affect project outcomes. Identifying the different concepts associated to project complexity, its main factors and characteristics, the different types of project complexity, and the main project complexity models, can be of great support in assisting the global project management community. In this paper, we give a general overview of how complexity has been investigated by the project management community and propose several ideas to address this topic in the future.

Key difference is that while project design is basically a part of planning stage, construction is mainly a part of implementation stage. According to PMBOK there should be a good amount of time in planning stage but in practice everybody gets hurry in this stage. Therefore, designs sometimes turn faulty. But due to time limit, the project is carried forward. To take time initially is a challenge.

I would suggest that one of the most significant unrecognised sources of complexity in digitally-enabled construction projects is software complexity, including hidden explore to the subset of software defects which result in exploitable cybersecurity vulnerabilities.

As increasing dependence is placed on software to perform functions which would previously have been performed by people who would have been working within the limits of their own knowledge and experience and with their work products being overseen by other people with at least the same level of knowledge and experience, a new dynamic is emerging in which users of software are no longer able to perform the work requested of them without correctly-functioning software. Meanwhile the people who write and maintain the software on which increasing dependence is being placed are far removed from the contexts in which it is being used and incapable of knowing what users need. Although I do not yet have empirical data to support what I am about to suggest, I would argue that awareness among construction sector end users, project managers and architects alike is very low that that software defect rates have never significantly decreased from historical averages of around 10 (Kandt, 2013) to 100 (Gately, 1999) defects per 1,000 software lines of code (KSLOCs) and that absolute lines of software code now typically run into the 10's of millions for common operating systems and significant applications such as Autodesk. As the absolute numbers of software lines of code increase, the complexity caused by unexpected interactions between defects increases exponentially, not in a linear manner. Even Windows Server 2003 had close to 30 million lines of code (Nagappan et al., 2006) and was the product of 10,000 software developers working for 3 years (Reid, 2004). More modern operating systems are considerably more complex.

If everyone working within construction were aware of a. the hidden 1% to 10% software defect rate; b. the difficulties of detecting software defects before release; and c. the difficulties of getting software defects fixed once discovered; then in my view the extent to which overall complexity is being underestimated would be greatly reduced....

Gately, A.A., 1999. Design and code inspection metrics. In International Conference on Software Management and Applications of Software Measurement, San Jose, Ca.

Kandt, R., 2013. Using Metrics to Assess Software Quality. Software Quality Professional, 15(3), p.39

Nagappan, N., Ball, T. and Murphy, B., 2006, November. Using historical in-process and product metrics for early estimation of software failures. In 2006 17th International Symposium on Software Reliability Engineering (pp. 62-74). IEEE.

Reid, R., 2004. Microsoft's Windows Server 2003 takes flight. Network World Canada, 14(9), p.18.