This series of blog posts are going to elaborate on Organisational Clogging, with focus on knowledge work, but it is valid for all organisations. The definition of clog is when something chokes a hole or place, and when we talk about our organisations, the clogging can be of two different kinds; people and activities. In our Prefilled Problem Picture Analysis Map the Organisational Clogging symptom looks like this when we ask why we have too much Project Administration waste and too much Activities in Queues waste.
This blog post is the introductory part, where we will elaborate especially on the phenomena of car congestions, i.e. queues of activities. In the second blog post in this series, we continue to discuss these two different kinds of Organisational Clogging in our organisations in more depth. Before we wrap-up this series, we will visit the world of ants and their anti-clogging-systems and also visit Toyota for their anti-clogging systems in both their Lean Production and their Lean Product Development.
One clogging phenomena often referred to, with examples in presentations mostly directed to Agile development, is traffic congestions that mainly clogs the roads during the rush hours. During the rush hours, the roads and their lanes become bottle necks, while the other hours during the 24 hours, everything works okay. And the reason why traffic congestions are referred to is that this is nothing that we want, and when sitting in the car queues, can do nothing about either. But, by referring to a phenomenon that seems to have no solution, but that only is something we need to live with, we lose focus and believe that our own Organisational Clogging neither is possible to solve too. We then frankly forget to ask why we have the clogging, why we have our queues. Because, if we not ask us why we have queues, we unnecessarily make ourselves to slaves under a chain of problems (symptoms). One big reason for not start to ask why we have queues is the tremendous articles and books about queueing techniques, Little’s law, etc. on isolated car or airport queues, that do not ask why we have the queues. Instead the focus is on variability for the arrival time, but sometimes also on the processing time. But, the examples with isolated queues are too simplified and not suitable for product development and not even production. This is because the processing time is diminished in importance, which is a terrible mistake, due to that the variability of processing times from the former processes, effect the arrival time in the example process. See this blog post about going to the root causes of queues.
Regarding car clogging at rush hours, if we ask why we have the queues, the answers are:
- too few lanes are expediting the cars and
- it is too many cars at the same time
These are both connected to our bad planning root cause, meaning we need over-capacity at the bottle necks, i.e. our Mean queues (see this blog post), and better planning so the cars more seldom come at the same time, and of course always have the variability regarding our processes and products in mind.
And traffic authorities try to take care about the planning, by making more and bigger roads with more lanes and by introducing pay stations with variable fee depending on the time of the passage, trying to force people to go with the cars before or after the rush hours. Even better is when the traffic authorities also make the commuting possibilities better, so people take bus, subway or train to work instead. What authorities normally do are more yanking then nudging with its citizens without knowing the unintended consequences, but in this case the solution with planning the cars is the correct one, so the yanking is actually appropriate (but, still a kind of manipulation).
But, clogging in the traffic is not due to that the cars are there for a common purpose, no, they are only one and one going to work. The same goes for the example of people at the airport going through the security control, they are neither working on a common task that make them clogged. There are neither interactions needed between the lanes/security staff, nor interdependencies between the cars/people queueing. The reason is that this is aggregating work, like in production, and not integrating work like in knowledge work.
Regarding our other root cause for queues about too little T-shape, it is already handled by the traffic lanes that can take care about any vehicle, and the security staff that can take care of any person that needs to pass the security control. And with empty bus lanes, of course the queues for the other vehicles are worse.
So, traffic congestions and queues to security controls are really treacherous examples when comparing it to Organisational Clogging in an organisation with for example Agile development. It is truly a simplistic example.
The other type of Organisational Clogging, is the clogging of people in the organisation, which are normally a big problem in silo organisations with projects. This clogging is at first sight not apparent, since it is a non-physical clogging. But, since we now have the knowledge of the human science numbers of 5 and 15, we know that they play an important role for us, which means that too many, and too many people, in the projects, meetings, discussions, problem solving, decisions, etc. must be avoided, which we brought up in this blog post about specialisation and narrowing of the competence.
In next blog post, we will continue to analyse Organisational Clogging more deeply. C u then.