|
|
|
|
|
|
by weinzierl
756 days ago
|
|
|
My point is that the "project" side is not really a "temporary endeavor undertaken to create a unique product" [1] in the majority of cases. Sure the environment, circumstances and result differs for every construction project, but the variance doesn't justify to call it a project in most cases in my opinion. We've built millions of modern bridges that are in operation and we've been doing it for more than 3000 years. The number of environments, configurations and requirements we've not already encountered is very limited and these are the real construction projects that - no doubt - do exist. Now, contrast this with the number of CRUD apps we've built and for how long we've been doing it. There is still a lot to learn there. That's the reason why more bridges are on time and budget than CRUD apps, in my opinion. [1] https://www.pmi.org/about/what-is-a-project |
|
|
Even if you're working on a "project" comprising hundreds of near identical houses, there could be massive differences in the project constraints and their solutions for adjacent plots for any given selection of houses.
There could for example be a large tree with root protection zones on site where you would have to carefully design the foundations to account for this and their future effects such as heave due to volume change potential of the underlying soil.
My point is that there are many "hidden" problems solved by the design team during the project / design phase even for seemingly insignificant or simpler "projects". In my experience of analysing and designing hundreds of buildings for over a decade every project was unique and as such treated like a "project".