These notes came into my mind during the last 3 years while working in tech and purely looking at the major problems of the architecture, engineering and construction industry. This is a series of post that I will be sharing the next weeks disseminating a talk that I gave an Autodesk internal conference regarding product development and complex systems frameworks.
During the last three years I have been thinking a lot about problems in the industry. A big part of being a product manager is to analyse problems and together with the team find creative solutions to fix it or even get rid of the problem completely. I also had a big influx of academia through my masters is Smart Cities at UCL and complex systems theory was a big part of that.
In today’s society we tend to analyse problems in a very simplified way, in that kind of logical - and we know that logic wins all…- With that cause and effect approach: meaning because of this now we have that. A very linear from a to point b. But the reality of it is that the biggest problems, the more important ones and the ones that I like to tackle are not cause-effect really, or at least they cannot be fixed in that way.
Most of those biggest and more important problems are actually systems problems, which shouldn’t be analyse in such cause-and-effect simplification. Thinking a lot about the architecture, engineering and construction industry during the last years got me to think that we should approach this industry more like a system or a complex system than as a cause-effect.
If we follow complex systems theory to analyse the issues in the AEC industry and particularly in construction, we will be able to have a better understanding of elements that otherwise would be ignored or not considered.
I personally started to use complex systems theory to analyse workflows in the context of construction. This is something that I strongly recommend to PMs working in the AEC industry. I even did an internal talk at Autodesk about it. Instead of looking at cause or effect problems or “point A to point B” approach look at it as a system that has a structure and behaviours that are interconnected. But first let’s understand complex systems, a complex system by wiki definition is:
“A system is a set of things- people, cells, molecules or whatever- interconnected in such a way that they produce their own pattern of behaviour over time.
A complex system is a system composed of many components which may [interact] with each other. Examples of complex systems are Earth's global climate, organisms, the human brain, infrastructure such as power grid, transportation or communication systems, complex software and electronic systems, social and economic organizations (like cities, an ecosystem, a living cell), and ultimately the entire universe.
Complex systems are systems whose behavior is intrinsically difficult to model due to the dependencies, competitions, relationships, or other types of interactions between their parts or between a given system and its environment. Systems that are "complex" have distinct properties that arise from these relationships, such as nonlinearity, emergence, spontaneous order, adaptation, and feedback loops, among others. Because such systems appear in a wide variety of fields, the commonalities among them have become the topic of their independent area of research. In many cases, it is useful to represent such a system as a network where the nodes represent the components and links to their interactions.”
I think AEC, and particularly construction is a complex system because is an assembly-like process, which is complicated, parallel and dynamic, and thus more complex and dynamic than project management often envisages. Looking at the definition of Donella H. Meadows in “Thinking in systems” I established a framework that has helped me analyse workflows and construction pain point through the last year. This is by applying her thinking in systems strategy and understanding the other definition of systems as: "A system is an interconnected set of elements that is coherently organized in a way that achieves something. If you look at that definition closely for a minute, you can see that a system must consist of three kinds of things: elements, interconnections, and a function or purpose."
And will leave complexity here for today: In Part II I will take a tangent to explain a bit more of product software development to set up the context of the following parts and the frameworks. In the meantime if you want to know more about systems, go ahead and check Meadows book, its great.
Comments