The Simplicity on the other Side of Complexity
Updated: Jan 27, 2020
An article published on January 22, 2020 in the Danish newspaper, Børsen which translates to “Nordea’s IT Transformation has headwinds: IT projects should be simple”, offers a refreshingly honest and accurate description of the problems that pervade the world of Digital/Business Transformation Projects. The authors build their arguments on the very valid premise that IT Transformation projects are increasing in complexity and with that complexity comes an exponential risk for failure. Yet there is a tiny assumption which they position as a “rule of thumb”, that the solution to this is to “keep it simple”, and that ubiquitous assumption is the key to understanding the real problems behind these projects. Although simplicity should indeed be the goal, it absolutely cannot be the means of dealing with complexity. And most projects make this catastrophic confusion.
First, let’s look at why aiming for simple solutions is valid. The author offers two very solid arguments for simplicity targeted goals which cannot be more accurate:
1) Simplify the architecture as much as possible. They give the example of one bank, one system and offer suggestions to limit the customization.
2) Make it clear what the system should help with. The business often comes with the solution instead of the problem which is a classic pitfall. Henry Ford once famously said about the invention of the car, “if I had asked the people what they wanted, they would have said faster horses”. Many projects are trying to build faster horses.
The above practices are widely known to be good practices and all implementation partners even near the class of Nordea’s cited partner, Accenture, are deeply familiar with and capable of working with these concepts. But if these simple rules are almost always applied in these projects, why are they still failing so frequently and dramatically? Transformation projects have more experts than ever working in them and the most sophisticated project management tools/methodologies available, yet the failure rate continues to rise.
This is a question I have been spending the past 9 months researching after removing myself from 13 years working in these “stuck” transformation projects in large Danish companies who were unable to deliver transformation. After a long and dramatically expensive global roll out of SAP, Maersk Line eventually turned the KPI boxes green and declared success in 2010 while pushing trolleys of champagne down the hallways of Esplanaden. By 2011 the project was deemed a failure and a new, quieter project rolled out its re-do. And they were the ones lucky enough to realize their marriage was doomed. Many other companies realize after implementing integrated enterprise solutions, they are stuck in unhappy marriages into which they have invested too much to divorce. Business processes rely on tons of laborious workarounds to be able to use the new systems, the data is too messy to enable decision making as it promised, and operations relies on excel to keep things running. The distinguished professor cited in the article from CBS is poignantly right about the fact that no one really wants to talk about it. Sure, you hear about failure rate statistics, but you don’t hear the stories.
My research has led me to believe that in our noble quest for simple solutions, we have allowed ourselves to demand and settle for the comfortable illusion of simplicity and this has had tragic consequences. Fortunately, complexity scientists understand specific ways to work with complexity and have been developing and using methods to crack complex problems for governments and militaries for decades; unfortunately, since the complexities in our IT projects have snuck up on us due to exponential integration capability increases, we haven’t taken the complexities in our projects seriously enough to incorporate these methods.
In 2007, an article was published in the Harvard Business Review about Situational Leadership. This article referred to a framework for decision making which is a cornerstone in Anthro-complexity science, yet it has been severely overlooked and widely misinterpreted for its project management implications. The model, which was created by Dave Snowden, is called the Cynefin Framework* and it makes a vital distinction between complex and complicated that is key to understanding what is going wrong with these projects.
Although it might seem a pedantic distinction since we use the words interchangeably when we are speaking casually, recognizing and working with the right methods within these situations is critical. The key to understanding the difference between “complex” and “complicated” lies in how much certainty you have in the predictability of the outcome of a situation. Although complicated things might be incredibly technical or difficult to understand, with the right knowledge and skills, a good solution can be found. But complexity occurs when the certainty of predictability lessens, and humans thrive in this domain, for good and bad. Once lots of different human interests and opinions are mixed into an otherwise complicated software implementation, it becomes very hard to control.
This may seem obvious to most people, so why is it important to make this distinction? Because project sponsors still want to cling to the illusion of control. In real life, humans are natural complexity navigators. But put us in a work situation where we need a KPI for everything with a target number to measure it by and suddenly we are expected to act un-human. This forces us to stifle the capabilities we have as a species to collaborate through our difficulties and arrive at the simplicity that is on the other side of conflict. And forces us to manage our complexities with templates designed for complicated things, where we need to communicate through stop lights and burn charts. And by doing this, elephants in the room grow, un-discussed, until projects fall over the cliff created by their forced simplicity into chaos and must start firefighting the unexpected trouble that ensues.
Anthro-complexity is quite an academic field so many people stay clear of the concepts because they seem “soft” or too theoretical. But in fact, tech can learn a lot from the humanities and I would like to draw out a few important examples that if adjusted, could lead us to getting transformation projects back on track.
1.) Keep doing this: It is indeed good practice to seek simple solutions to complicated problems. And implementing systems is a complicated “problem”.
It is best to get experts to help do these projects, and just as the author suggests, they are best served in this space to crave and seek the simplest but still valid solution. For those of you who like the academia behind this, Occam’s razor supports this. But if you prefer more practical supporting evidence, there is usually no shortage of consultants on these projects to shout "keep it simple, stupid" at you. And that many experts can't be wrong.
However, one pitfall when working with a high level of complicated things with multiple experts is that there is not one “best practice” solution to complicated things. So, when your experts start to encounter conflict between them, this could be because they are each trying to position their “good” solution as the “only” or “best practice” solution. This is when the situation becomes complex. It is critical to encourage your experts to listen to others, even non-technical experts and exercise an open mind in deciding together which of the good solutions they will go with. This is not to say one should disregard facts and let everyone’s opinion into your solution. It is just a recognition that there is not only one solution to complicated problems.
2.) Although implementing systems is complicated, implementing systems within an organization filled with people is complex.
It is not good practice to require simple and predictable solutions to complex problems. Rather, it is good practice to influence patterns that move toward good, away from bad, and set the scene for simple, yet unpredictable solutions to emerge. This distinction is indeed the source of the real problems in transformation. Although implementing systems in a vacuum can be done with experts trying to follow good practice and keep things simple, once you add in the human factor you are now working with a complex situation. Vice presidents are each trying to deliver on often competing KPIs; business operation teams are trying to do their jobs but project people keep interrupting them with supposed “improvements” that seem completely senseless and harder to execute than what they are already doing; changes in the organization structures are happening more than ever before; mergers & acquisitions occur; other projects are competing with your transformation, etc. Suddenly your project that experts should have been able to do if they just followed this illusive “best practice” that everyone had false hope for has failed.
The pitfall here is that companies crave the predictability of project success so much that they expect their vendors and project managers to use “best practice” tools that promise predictable and measurable outputs in order give decision makers security with the business case to make the investment. Then we put traffic lights on score cards to measure success and project managers feel ashamed if they can’t keep them green or have a plan to turn back to green straight away. But these tools aren’t designed to manage human complexity.
I am not advocating against great project structures and measurement tools; we should still expect our vendors and project managers to have them, and they should still be used for the complicated parts of the projects. But there needs to also be a focused effort made to openly discuss the complexities that abound in a structured way, without blame games ensuing. We need to recognize that human complexities are not predictable and stop trying to use system thinking tools to manage them in our projects.
3.) Projects know the human factor is tricky, so they use Change management tools to manage them. But Change management treats the humans involved as objects receiving change instead of the subjects and drivers of change.
Projects “manage their stakeholders” by post-it-noting them up on a chart in order to map out their feelings most of the time without ever getting them into the room. They know Suzy from accounting will resist change and she has power and they have a handy chart to tell you what they are going to do about it. They craft training plans and communication plans and if done successfully, they can help the transformation decently. But they rely on toolboxes designed by systems thinking practices that come from Taylorism, thus reduce employees to factors of production instead working with them as an organic whole.
These tools are great if you want to optimize predictable things like your accounting processes or streamline your assembly line, but are absolutely the wrong thing to be doing when you are working with uncertainty which is what you are always doing when you are working with humans. Human behavior is not predictable because we have a species-specific capability of moving between identities and thus contextual shifts cannot be combined with these identity shifts to accurate predict our behavior.
A major pitfall here is that since we try to manage the mix of humans involved in our complicated systems work with simple tools, we fool ourselves into thinking they are simple problems. Major conflicts that inevitably arise between highly competent partners or stakeholders about how to handle complicated things are handled behind the scenes in unstructured dramas that play out behind closed doors. The courageous discussions with the steering committee that should happen, don’t because no one wants to put their neck out and be the one who can’t handle this “soft” human stuff that they should have a “best practice process” to handle. These dramas eat away at the project efficiency, team motivation and eventually delivery quality to the point where the project either becomes completely paralyzed or delivers a product that has little or no value to the business.
So many times, I have watched the few brave project managers who try to properly address these “elephants in the room” get hung out to dry because the steering committee considers it the project manager’s job to fix them with a spreadsheet instead of a leader supported group conversation. They learn to choose their battles wisely if they want to keep their job. And management consultants and implementation partners have learned this too. In 2015, I co- developed an action plan with McKinsey to improve LEO Pharma’s SAP project that was severely paralyzed and running at a high burn rate. There was one huge elephant at the top of the list. Yet the night before we presented it to the steering group, the McKinsey lead speculated that two heavily influential VPs did not want to hear this advice. He removed it from the recommendation on the premise that “in life, you have to identify which battles you have the chance to win, and if you have no chance to win them, do not take them.” Another elephant to put to the side.
4.) Although Agile methodologies can be a better tool to bring the human complexity into relationship with the complicated, the industrialization of the methods, combined with the dogmatism surrounding them have in many cases diluted the founding mindset that made them great.
Indeed, Agile has improved the systems development process drastically by bringing the business closer to the developers sooner, helping projects understand how to work iteratively, and by reducing some unnecessary linear thinking. In fact, Agile was birthed by complexity scientists who understood that “probing” is the first step necessary to handling a complex problem. But somewhere along the way, the industrialization of agile has manifested in organizations as a “one size fits all” silver bullet for all things in many projects. The bastardization of complexity thinking that the mainstreaming of Agile has caused, have brought us people in projects who use “agile” as an excuse to be sloppy. Others advocate “safe to fail” for things that indeed are not “safe to fail” and advocate for collaboration for all things which is certainly not the point! They seem to forget that just because complexity navigating methods encourage the increase of variety of inputs and purposeful invitation of naïveté into our thinking, there should still be measures in place to monitor and control the work done using these methods. Some make the same mistake as the simplicity preachers by not factoring in the importance of using agile tools in the right situations.
5.) The only silver bullet is that there is no silver bullet
The beauty of complexity science is that it gives a framework to recognize and navigate the complex and the complicated situationally. It is not a one size fits all solution, but rather a framework for understanding the importance of recognizing uncertainty, embracing it, and navigating towards improving qualitative patterns or quantitative statistics according to what is most appropriate for the situation. And the best news is, if you work from an understanding of this, then the change management, agile and other great project tools we all have come to rely on, can be free to actually do the great things each are capable of doing in their appropriate situations.
In Business/Digital Transformation projects this would look like bringing human resource-like activities front and center. It goes against the crutch grabbing impulse that if we get enough of the right project management and technical experts into the project, we will succeed. Every failed project I have seen has groups of business professionals who think IT and the Implementation Partners were horrible and ruined the implementation; has IT folks who think the business is ignorant; and has implementation partners who have plugged in a system that technically works, turned on the green lights, and blames the business for whatever aftermath they have brought upon themselves. And neither of them is completely wrong. Our societal addiction to the binary thinking that leads us to believe someone is always to blame is a blocker to understanding and working with complexity. Computer programming was also once limited by an either/or approach. But once quantum computing realized that “or” is also an option, massive amounts of tech innovation occurred.
We need to think and encourage thinking quantumly if we are ever going to get more consistent success rates for these projects that are just going to keep getting more complex. We need to open space in our projects for curiosity, sparring, questioning, disagreeing, and challenging. In fact, I think we need to put “noise management” at the top of our agenda instead of aiming to avoid the noise. Experts working in projects love to chant “keep it simple, stupid”. But we all need to remember that is only good advice for complicated things. We need to embrace complexity instead of avoiding it, because that is where we are going to find the serendipitous collisions that lead to emergence if we can all get past our egos. And emergence ironically also leads to simplicity.
Oliver Wendell Holmes once said, "For the simplicity that lies this side of complexity, I would not give a fig, but for the simplicity that lies on the other side of complexity, I would give my life." Our projects need to take actions that lead to both kinds of simplicity, but not let a hunger for the possibility to find the obvious in all contexts, lead us to avoid putting in the work to find the beautiful simplicity that lies on the other side of complexity.
*There are many versions of Cynefin, but this is the Liminal Framework as published by Cognitive Edge The Cognitive Edge method is ©2012 Cognitive Edge (USA) Inc., used under a Creative Commons Attribution-Noncommercial-Noderivs license: http://creativecommons.org/licenses/by-nc-nd/3.0/.