Published
We often think of languages in terms of the foreign languages we may have learned at school but this overlooks the fact that business, engineering, IT and even conceptual ideas have a vocabulary and indeed a grammar of their own. This technical jargon is often seen as problematic, acting as a barrier to understanding for people who aren’t fortunate enough to have learned the language. That is certainly true and it puts great onus on you to think about the people with whom you are communicating. Are they familiar with the language of projects (think about all of the hundreds of acronyms we use), or the language of a discipline like civil engineering or that is particular to given industries such as construction, nuclear power, rail transport or defence. You need to be careful to translate what you are saying into a form of words that is inclusive and appropriate for your audience.
There is a reason for these technical language sets. They have been created to describe, ideas and processes for which we previously didn’t have words. And this puts an onus on those involved in projects to seek out and learn the languages you need. If you are a project sponsor, for example, take a moment to query those who are communicating with you to ask them about terms or techniques with which you may not be familiar.
The world of complexity and systems thinking, which we increasingly recognise as important for understanding how major projects work, has its own language and grammar. The good news, however, that you can pick this up and start using it, a principle at a time. To that end, we have started a series today that will explore a number of the 33 systems laws and principles.
The first one is the Viability Principle, which you will be familiar with, even if you have never put a name to a concept. Think about the way that major projects need to balance control and agility, change and business-as-usual or even the immediate needs of the project delivery and the emerging needs of the future users. Balancing these various competing tensions are what is expressed in the Viability Principle. If you don’t balance the competing tensions then you bring the project’s viability into question. Think about it. If, for example, you put all of your emphasis on project delivery and ignore the emerging needs of your future users, you will deliver your project but will have effectively stripped the value out of the assets you have delivered.
We’ll continue to add a new principle each week to the Grammar of Systems series. Please take time to look at them; they will all be very short and they are on video. Please also share them with colleagues and let’s start learning the language together.