Making complex things look simple is extremely challenging. It takes an enormous amount of work and effort to do. It can be a frustrating, head-banging and hair-pulling experience. It is also really, really important if we’re going to collaborate and solve complex and difficult problems.
Part of the challenge is how we tend to respond in the face of complexity. Our natural instinct is to try to simplify: we endeavour to find straightforward representations, to find substitutions or to focus in on one part of the problem (while ignoring the rest). All of these are very human responses that our brains implicitly encourage us to adopt. Cognitively, we’re lazy; we look for an easy solution. When our minds offer us a simple explanation for something that looks hard, we grab onto it with all the enthusiasm of a puppy with a bone.
While a simplified take on a complex situation can be enormously appealing, it can also be entirely dangerous. Substituting a simple problem for a complex one might feel comforting. It creates the appearance of confidence, and of defining a direction forward. At the same time, it can be misplaced confidence taking us in a direction that is misleading and inappropriate.
The challenge here is that while we are trying to get from complex to simple, we often wind up going instead with simplistic. A simple representation looks at the whole problem and keeps in place the essential details necessary to fully understand what’s going on. A simplistic representation leaves out significant aspects of the actual problem, focussing only on one part of the situation while ignoring significant other aspects.
As an example, think about a map. Maps are incredibly useful devices, in that they serve to create a comprehensible view of very detailed geography. The map isn’t the territory, but it is a representation of the territory. It works by highlighting specific features of concern (roads, for example) and broadly ignoring everything else. A roadmap is a great means of figuring out how to get from point A to point B. A topographical map is a surprisingly good way of getting a lay of the land (literally) by showing its contours. Each serves a purpose, and when you understand what each is trying to do, they are simple enough to understand.
Depending upon the magnitude of the problem, we need to zoom in and out of the territory; we need a map of a different scale. A tourist map of a city provides one resolution, highlighting the major features someone might care about seeing. A Michelin map book operates at a wholly different scale, showing every lane and cart path. We choose the representation we need. Each is complete in their own way, in that they fully explain the territory at the level of detail appropriate for the job. They are simple and (usually) clear.
At the same time, a line diagram drawn to explain how to get to a particular store or restaurant, drawn on the back of a napkin, is simplistic. It maps only the route we need to follow, starting from a dot that explains where we are and ending with an ‘x’ at our destination. A line connects the dots, perhaps with a couple of cross streets highlighted as small ticks. In theory, it is everything we need to guide us to our very specific destination. In practice, there are a lot of potential pitfalls along the way.
The challenge of a simplistic representation is that it doesn’t prepare us for what we might encounter. Make a wrong turn, lose count of cross streets, or start in the wrong direction and our simplistic representation becomes not only useless, it becomes dangerous. The challenge is that, unfamiliar as we are with the territory, we may not realize our mistake until it’s too late. We may carry on with presumed confidence, but wind up getting more and more lost.
This analogy holds fairly well when we start to talk about complex problems and projects in our organizations. We need to be able to understand the overall context that we are dealing with, and the features that are relevant. We need to know how everything fits together. We need to be able to focus on the whole problem, rather than isolated aspects. Otherwise we risk solving one thing while creating any number of unintended related consequences and impacts elsewhere.
Doing so means finding some way of representing the problem that is meaningful and useful. This is exactly the issue I encountered working with a customer over the last few weeks. I’m helping them to develop an overall roadmap of the significant organizational change projects they are contemplating. It’s an ambitious scope of work. It will require a lot of effort to manage and deliver the projects, and it will require even more effort to absorb the results and use them as an organization.
The rationale for developing the roadmap began with a need to understand the impacts that this program of work would have. There were very real questions and concerns about whether they had the capacity to do the work, and also essential questions about whether they could absorb the results. There was also some appreciation that there were overlaps and dependencies between the projects that needed to be understood, but that wasn’t broadly recognized as a problem.
Working with each of the individual projects, it emerged very quickly just how tightly some of the initiatives integrate together, in a variety of different ways. There are dependencies in terms of data, of function, of process and of system. There are integration points that need to be planned collectively before key decision points arrive—or essential deliverables get produced—individually. There are overall project coordination and change management activities that need to be in place to ensure that the effort is successful, not just any one individual project.
The challenge came in how to convey and communicate this complexity so that people could understand it. Looking at each project in turn was insufficient because that didn’t adequately represent how the project fit into the larger change effort. Looking at each problem in turn was also inadequate in that it ignored the overall coordination that was necessary. Communicating the total picture required finding a way to represent the information in a way that was simple, but not simplistic.
Different disciplines (project management, change management, systems analysis) offer different techniques and perspectives of representing information. Each of these possible representations had their own challenges, however, particularly in what they emphasize and the level of detail that they reflect. What I needed to do was be able to provide a simple way to demonstrate the complexity contained within the program, that didn’t in its own way complicate being able to understand the situation.
Doing so required a fair amount of thinking, testing and exploration. It ultimately required not one, but four different views of the problem. Each representation looked at the program through a different lens. There was a perspective of the work dependencies, the change management dependencies, the relationship between the projects themselves and the relationships between the various systems that the projects would produce. While each view was different and spoke to a different concern, each also provided a complete view of what was happening, in a manner that was as clear as possible.
The result was four clear maps of the overall program, one for each perspective being explored. On paper, they look simple and straightforward. There is a lot going on, but at the same time it is clear and obvious what is actually being illustrated. The story is relatively self-explanatory, and the complexity is readily visible.
The process of getting to that level of clarity was an iterative back and forth between building a detailed understanding, and striving to create a summary representation that worked and made sense. Much as I might have liked to, I couldn’t jump to the finish line of finding a means of communication that worked. First I needed to dive deeply (very deeply!) into the projects. I ultimately wound up producing an extensive brain dump of everything that I knew, everything that was important and everything that was interconnected for each of the projects. From there, I could sift and sort and structure and start to build a representation that made sense.
As we deal with more and more complex challenges, it’s important to recognize that one of our biggest obstacles is in getting others to see the true magnitude of the complexity we are facing, and appreciating it for what it is. That requires incredibly clear communications, and takes a lot of work to do. You are trying to make the complex simple, in order to understand and appreciate the complexity. That’s a pretty meta concept to get your head around. It’s a pretty important one as well.
Albert Einstein has had the statement frequently attributed to him: “If you can’t explain it to a six-year-old, you don’t understand it yourself.” Without quibbling over what age you should be targeting, there is a great deal of truth in that quotation. When we flounder and stumble in explaining complex and difficult subjects, it’s usually because our own mastery is still on shaky footings. With mastery of understanding can come simplicity of explanation. We need to communicate simply, but we need to not lose sight of why we are trying to do so: to make the complexity of the situation comprehensible. To do that, we need to go deep.