Systems thinking and quality

A few days ago I rediscovered a short presentation that Dr. Russell Ackoff gave in 1994. The recording of this presentation was titled “If Russ Ackoff had given a TED talk…” on YouTube. The presentation is really short – just 12 minutes. But it contains a lot of wisdom, probably too much to understand it all at once.

I meanwhile watched the presentation several times and I am still not sure if I really got my head wrapped around all details. While the ideas and examples that Ackoff present feel simple and straightforward, I think it is surprisingly hard to really understand their consequences for our daily challenges. That’s why I decided to present and discuss them in this post – of course not claiming for myself that I completely understood what Russ Ackoff said.

Definition of quality

Ackoff starts with noting that many quality improvement initiatives are considered failures and that experts then often start to discuss if quality was defined correctly. Russ Ackoff counters those discussions with a very simple, yet powerful definition of quality:

The definition of quality has to do with meeting or exceeding the expectations of the customer or the consumer. Therefore, if their expectations are not met, it’s a failure.

It was easy for me to agree with that definition because it underlines my understanding of quality: quality is in the eye of the beholder and (not only) in software development the most important stakeholders typically are the client and/or the user.

I have seen lots of software teams where quality was merely reduced to test coverage and how “clean” the code is. Customer expectations? Nil return. I will come back to the topic of quality in software development projects in some later blog posts.

Definition of a system

Russ Ackoff continues with a definition of a system:

A system is a whole that consists of parts each of which can affect its behavior or its properties. Each part of the system when it affects the system is dependent for its effect on some other part. In other words: The parts are interdependent.

He immediately derives from that definition:

No part of the system or a collection of parts of the system has an independent effect on it. Therefore a system as a whole cannot be divided into independent parts.

If we let that sink in for a moment, we start to realize that whenever we deal with a system (what we often do),

• divide and conquer techniques are doomed to fail
• local optimizations do have little effect
• we cannot infer the effect of a change by just looking at one part
• we cannot predict the future behavior of a part by looking at it in isolation

and more.

I have to admit that even if I tend to think in systems a lot, I am not sure if I put enough attention to this interdependence aspect of systems. I am afraid, I did not. Taking the interdependence into account leads you to still different ways of reasoning about systems.

Emerging system properties

Ackoff then derives two implications from what he said before. The first one is:

The essential or defining properties of any system are properties of the whole which none of its parts have.

He illustrates it using the automobile as an example:

The essential property of an automobile is that it can carry you from one place to another. No part of an automobile can do that.

This caused an spontaneous “Wow, how could I oversee that!” in me. I mean, if you read it here, it feels straightforward, doesn’t it? But quite likely you did not think about this implication in this way before. At least I did not.

Also, I think this implication is hard to overestimate. It especially means we cannot understand the purpose of a system and how it works by looking at its parts. But that is what we usually do. We just look at the parts, what they do – and sometimes also how they interact. But by doing this, we have no chance to derive from it what the whole does. We need to look at the whole to understand it.

Russ Ackoff reinforces his statement by adding:

Therefore, when a system is taken apart it loses its essential properties. A system is not the sum of the behavior of its parts, it’s a product of their interactions.

I think, it is important to have that in mind when thinking about changing organization, processes or other types of systems. The secret are not the parts; the secret are the interactions. Additionally, if we change a part, we should not measure if the behavior of the part improves, but if the overall behavior of the whole improves – with respect to its essential properties.

The problem with local optimization

Coming back to (continuous) improvement, the second core topic of his talk, Ackoff concludes:

If we have a system of improvement that’s directed at improving the parts taken separately you can be absolutely sure that the performance of the whole will not be improved.

He illustrates that again using an automobile as example. He says, that you should imagine having all cars available in a room and then ask a group of experts to identify the best engine, the best battery, the best transmission, and so on. Afterwards, you take all the parts identified and put them together. While we would expect to get the best car possible (we only use the best parts available), we do not even get an automobile because the parts do not fit.

This leads Ackoff to the conclusion:

The performance of a system depend on how the parts fit, not how they act taken separately.

The example again seems to be easy to grasp, but if we think a bit longer about it, it adds another vital point of view: whenever we try to change or optimize a system by only looking at the parts and without understanding the purpose of a system, i.e., its emerging properties, it is very likely that we do the wrong thing because we did not understand how to change the parts in order to optimize the system. We run in similar problems if we ignore the interaction pattern between the parts.

The trouble is that we are so used to “divide and conquer” for solving any kind of problem that we tend to forget to look at the emergent properties of systems and their consequences.

Always keep track of the whole while improving

Ackoff then gives an example how to do improvement work better by looking at the work of an architect (the one that designs houses, not software). The architect will start the design based on some desired properties provided by the client, Ackoff says. The architect will never start with the design of the rooms, but with a design of the house (the system). Then she will start to design the rooms in a way that they fit in the design of the house. Sometimes she might go back and change the design of the house if it improves the quality of the rooms – going forth and back until the design is done.

But (s)he will never modify the house to improve the quality of the room unless the quality of the house is simultaneously improved. That’s fundamentally the principle that ought to be used in continuous improvement.

Personally, I think that no matter if the improvement is a continuous one or not, we forget way too often to keep the desired properties of the whole (the system) in mind when trying to improve it.

Most “maturity models” and “improvement initiatives” I have seen try to figure out which parts need to be improved and then solely focus on optimizing those parts until the local quality metrics are fine – not bothering for a second if the overall system improved by all these measures or not.

That is why I prefer “capability models”. They also define several parts, called “capabilities” that can be subject of improvement activities. But they never measure how the part improved. They measure how the whole improved. This is a very different and IMO much better approach for most places that are subject to any kind of improvement initiative.

Fixing failures ≠ improving performance

Ackoff then comes to his 2nd implication. He states that quality improvement is usually based on the concepts developed by Walter Shewhart which is about identifying and removing defects. While removing defects is a relevant activity, Ackoff states:

A defect is something that’s wrong. When you get rid of something that you don’t want you don’t necessarily get what you do want. And so, finding deficiencies and getting rid of them is not a way of improving the performance of a system.

This observation leads him to a core principle:

Basic principle: An improvement program must be directed at what you want, not at what you don’t want.

Especially in software development, we are often obsessed with defects and “technical debt”, including heated discussions about clean code, test coverage and alike – a lot more than with delivering what the client actually wants to have. While there is a value in those activities, they are not enough from a quality perspective. The absence of defects does not mean that the application does what the client expects. ¹

This is a rich and deep topic, especially in the software development domain. Therefore, I will discuss quality in more detail in some later posts.

Discontinuous improvement

Ackoff then makes two more very interesting points in his talk. The first one is about the importance of discontinuous improvement:

Continuous improvement isn’t nearly as important as discontinuous improvement. […] One never becomes a leader ² by continuously improving. That’s imitation of the leader. You never overcome a leader by imitating and improving slightly. You only become a leader by leapfrogging those who are ahead of you and that comes about through creativity.

This point was especially interesting for me because I am a big advocate of continuous improvement. So, while continuous improvement is a good thing, it is not sufficient if you actually want to become a (market) leader in what you are doing. You need some bigger, creative steps for that.

I have to admit that it made me think – and still makes me think. I guess, I will stick with continuous improvement, but I understood that sometimes something more is needed.

Doing the right thing

Russ Ackoff finishes his talk with a warning. He starts it with pointing to the poster children of continuous improvement at the time of his talk (1994):

We frequently point to the Japanese and what they have done to the automobile: there is no doubt that they have improved the quality of the automobile. But it’s a wrong kind of quality.

After this unexpected statement, he starts to explain:

Peter Drucker made a very fundamental distinction between doing things right and doing the right thing. The Japanese are doing things right, but they are doing the wrong thing. Doing the wrong thing right is not nearly as good as doing the right thing wrong.

Ackoff explains that it is the wrong thing by pointing to the pollution that automobiles cause especially in big cities and the effects, the pollution has on the health of the people living in areas with high automobile traffic. I have to admit that I find his critical thinking really remarkable – especially back in 1994 when very few people were thinking about such problems.

He continues his warning by generalizing on the concept of quality:

It’s a wrong concept of quality. Quality ought to contain a notion of value, not merely efficiency. That’s a difference between efficiency and effectiveness. Quality ought to be directed at effectiveness.

To keep it short: I could not agree more!

Ackoff then finishes his talk with the words:

The difference between efficiency and effectiveness is a difference between knowledge and wisdom, and unfortunately we don’t have enough wisdom to go around. Until managers take into account the systemic nature of their organizations, most of their efforts to improve their performance are doomed to failure.

I can only guess how often Dr. Ackoff hit the walls of ignorance in his career to end his talk with such disillusioned words.

Wrapping up

This was a lot of stuff covered in just a 12 minute presentation. I remember a lot of presentations that took an hour that did not even contain a fraction of noteworthy takeaways. Personally I think, more than 25 years later, Ackoff’s talk is still as relevant as it was in 1994.

I hope I was able to bring his points across in this post and would be glad if it also contained some valuable insights for you.