This series will dig into the importance of having a common vocabulary when having discussions especially between different disciplines.
Why is this important?
It is important to be able to have a common language, so we understand each other, especially when we come from different disciplines like; complexity theory, logic, mathematics, human science, project management, organisation theory, etc.
And why is that important?
That is to be able to work transdisciplinary, and use the information between the disciplines in order to make extraordinary innovations, or even exaptations, when using and combining knowledge and experience from one or several disciplines, to combine to a new total, a systemic solution.
But, when we go deep into a discipline, the more difficult vocabulary we need to use for that specific discipline, to point out what we want to say. This, so we can use one specific word instead of several sentences to explain something, where the latter most probably won’t do the job anyway. But, as long as we do not go into bits and bytes of respective discipline, it is certainly possible to have a common non-difficult vocabulary, which means that we easier can understand each other.
So, when we talk the same “language” and therefore easier understand each other we can definitely easier; 1) use knowledge from many disciplines (chance for systemic solutions) 2) use knowledge from one or more disciplines in another discipline (chance for exaptations); 2) do work together, so called transdisciplinary work to achieve 2a) a common platform, for example to a car or a telecom base station and; 2b) an IT platform, for example in a bank, where different disciplines like loan, savings, etc. can use common modules.
All together this means that each discipline does not need to re-invent the same wheel again, or invent many similar wheels, or invent every part of their respective wheel themselves.
One big problem is when common words in one discipline get a negative meaning in another discipline, even though these words for a long time are the one to use to describe something. Project is one word, that of some reason is rejected in our Agile world, even though it has this clear meaning, here from Cambridge Dictionary :
project – a piece of planned work or an activity that is finished over a period of time and intended to achieve a particular purpose
The word project will be further discussed in the second blog post in this series, and all the consequences this has led to when the Agile movement has rejected to use the word.
Cause and effect are two other words, that is often combined and have a negative meaning in for example complexity theory. The reason is that in some circumstance they are so integrated that they always seems to mean linear cause and effect, even do they do not mean that, which will be brought up in third blog post in this series. Due to their importance in order to have a common vocabulary, especially between when we have order and when we do not have order in our different ways of working, we will take them in a separate blog post as well.
We also have problems with the word problem, and that is problematic. The reason is that the word problem is used both when we try solve an intractable problem (caused), or when we are trying to figure out the activities for our new product (non-caused). This is problematic since caused and non-caused problems are very different.
Unknown unknowns , known knowns and known unknowns are famous from a quote made by Donald Rumsfeld . Later also unknown knowns have been added , and will be brought up in the fourth and last blog post in this series. The meaning of the first of them is quite clear, but the interpretation of the last one is more ambigous. They are many times also put in the Cynefin™ Framework, with many different solutions, which generates more ambiguity. By logic, we will one time for all elaborate on this and put them right this time. So, it is not only about using the same vocabulary, but also find out what they really mean for product development, service, production etc. when we are having problems that leads to chaos, in our complex organisation. With ambiguity we will frankly not take the right decisions, so we need to sort this out.
This was the introduction blog post in this series.
C u tomorrow in the next blog post about project.
 Wikipedia. Unknown unknowns. Link copied 2019-06-08.
 NASA presentation at the OSMA Software Assurance Symposium 2003. One of the first references with all four combinations of un and known.
Link copied 2019-05-28.