Issues appear, seemingly out of the blue, often late in a project, or at the most inopportune moment. Project budgets and timelines are impacted, and client trust is threatened. These are common experiences for engineering projects across most organisations, although their sales and marketing material will try to convince you otherwise.
Why does this happen? After all, the people are competent and well-meaning, they make the best decisions they can, with the data available to them, and yet often the outcomes are still surprising and/or disappointing.
Often, people try to assign blame, either internal or external; maybe a better plan is needed, a different approach, more expertise, or a different supplier. One or two might be picked as “lessons learnt”, but then it is onto the next project. Sure enough, the next project starts, the lessons learnt are implemented, and this time…
…a different issue arises!
For everyone involved this can be a frustrating experience, it feels like playing whack-a-mole, you fix one issue, only for another to pop up somewhere else. If this feels familiar, you’re not failing, you’re operating past the limits of intuitive problem-solving.
This pattern of reoccurring, but different problems, is a symptom. People aren’t making bad decisions; the problem lies with the underlying system and addressing the root causes requires a good understanding of that system.
What do we mean by “a system”?
If problems are not isolated issues, but properties of an underlying system, we need to be clear about what we mean by a ‘system’. Let’s start with a definition:
“Multiple components, interconnected so as to achieve a larger outcome.”
It is important to remember that systems are a conceptual model, and “all models are wrong, but some models are useful”, so the aim is not perfection or accuracy but understanding, intuition, and useful outputs. The concept of a system can be used to model anything, including engineering systems, organisational systems, natural systems, and any combination thereof. This makes them a valuable tool to understand the complexity of the real-world, especially where multiple domains intersect.
The key elements of a system are:
- Components: not necessarily engineering components (although they can be), but discrete entities which do something in of themselves. These components can in turn be considered as sub-systems, and our system is in turn a component of a larger system.
- Interconnections: physical or abstract connections between components. In engineering contexts these are often physical transfers: data, energy, or matter. But they can also be more abstract connections: support, education, protection, or attention.
- Purpose: all systems have a purpose, it is not a declared “mission statement” or similar, but rather the collective outcome that the system acts to achieve. Systems can have more than one purpose. They can be designed, as is common with an engineered system such as a vehicle or machine, but they can also be an emergent property.
Given that systems can be arbitrarily large and complex (in theory you could model all of life, the universe and everything), it is important to explicitly declare a system boundary. This enables us to consider components as in or out of scope. We can draw the boundary of a system at any point (temporal, logical or physical), and the question of where to draw the boundary is both arbitrary and important.
We model systems for a reason, usually to gain a better understanding, either as an end goal, or to support a broader aim. For a given reason, there exists a natural system boundary. It is tempting to draw system boundaries along traditional organisation, hierarchy, or historical lines, but unless your reason is directly tied to that existing boundary (“how does my organisation work as a system?” and similar questions), this can be a trap. Many system connections cross traditional boundaries, and where you draw the system boundary influences what and who becomes visible within your model.
People who interact with a system are often totally unaware of the system’s existence (as a system), only being aware of physical or hierarchical components, or events where the system interacts with them. Even when aware of a system, people have often not considered its purpose, and multiple people can have different views. None of these views are right or wrong, but they can provide deep insight into how that person is connected to the system.
Natural systems often have continued survival (and reproduction/growth) as an emergent purpose. Interestingly, organisations which don’t have a designed purpose also tend to gravitate towards survival and abstract growth as their emergent purpose.
Why do systems matter?
The reoccurring pattern described at the start of this post (late surprises, reactive fixes, and lessons that never quite stick), is a very likely outcome when a complex system is not considered as such. Without systems thinking, interventions naturally focus on the most visible symptoms, while the structures that produce them remain unchanged.
This is why attempts to fix individual problems often feel like playing whack-a-mole. Each fix addresses a symptom, not the system structure that caused it, so new problems continue to emerge elsewhere. Lessons-learned cycles may prevent similar issues in future but rarely uncover and address the underlying causes.
Systems thinking is non-intuitive, but it matters because it provides a model by which to understand the complexity that is common in the real world. That understanding is critical to reliably improving or building new systems.
In future posts, I’ll expand on systems thinking further and introduce simple and practical ways to see past events and into structure.