Three strategies for analysing ‘wicked’ business problems.

‘Wicked’ problems are a puzzle, wrapped up in a conundrum, and nestled deep inside an enigma (to paraphrase Churchill). They are enormously complex problems that demand decisions from us that have significant consequences. Sounds familiar?

We are living in uncertain times and many of us have extremely difficult decisions to make. Good strategies for making evidence-led decisions have never been more important.

Decisions about new business models, service innovations, new product variants and organisational transformation.

Whether your job demands strategic or operational decisions, there will always be some absolute monster decisions. Some business decisions will be massively complex, and they will risk everything, if you get them wrong...

But it so happens that I did a PhD in complex systems, so here’s a few suggestions.

What is a Wicked Problem?

First, let's be clear on what we are talking about. A wicked problem has several characteristics which make it totally different to a normal business problem. 

1.     Wicked problems have strong very links between their elements. When one part affects another part, which affects another part and so on – it makes forecasting impossible, it makes considering all your options unmanageable, and it can cause diminishing returns when you scale-up.

2.     There is no definitive way to formulate a wicked problem, it’s difficult to pin down and difficult to describe – this is critical because how you describe a problem greatly effects your approach to solving it and getting sign-off.

3.     Solutions to wicked problems are subjective. Different stakeholders will judge the quality of your solution in different ways – some people will always hate your solution.

4.     There might not actually be a solution. Or there might be more than one solution, all with different advantages and disadvantages – there might be no perfect solution.

5.     Solutions to wicked problems have to be explained in different ways. Which influences follow on actions – like selling it to your boss, your client, or your partner (not necessarily in that order).

6.     Evaluating solutions to wicked problems depends on the whole situation, like the environment the company or the customer is in – solutions depend on context, and context changes.

7.     Finally, each wicked problem is frequently related to another wicked problem.

I know, that last one is the worst! A real killer, but I have some suggestions below.

Three ways to tackle Wicked Problems

The things that makes wicked problems so wicked are the complex interlinking and interrelations that exist within them. Like when one solution either depends on something else, or when it causes unforeseen consequences. Or when different stakeholders have different aims, objectives, and even different ways of evaluating results.

So, a general way to solve wicked problems is to break some of these links. And that’s how these suggestions work:

1. Look for the underlying structure and use it to focus your resources

Every wicked problem has a structure, and there is usually something about the problem that doesn’t change, or that changes slowly. Larger structural features can be found by using some method like the ‘80/20 Rule’ or the Pareto Principle. Structural features are like when most of your problems come from relatively few causes, or when most of your profits come from a few customers.

Complex systems always have constraints, or limits or ‘edges’. A system’s constraints shape its form – or its behaviours – into fundamental features which can be recognised and then used.

(Nobel Prize winner Herbert Simon pointed out that without constraints to give them some sort of structure, complex systems would be impossible to perceive as things.)

It is these fundamental structural features that we look for when we analyse data.

Some structural features will be obvious to our normal senses. Like Frequently Asked Questions from customers. Some structural features will be easy to see, like patterns you can find using normal statistical analysis. And some features will be the extremely complicated and hard to find patterns that we use machine learning to look for. Like neural network AI models.

The structural features of the problem will help you to prioritise your time and resources. Like when a production manager uses the ‘80/20 Rule’ to focus on the 10% of problems which cause 70% of the waste. Or when a VP of Customer Success uses customers' most Frequently Asked Questions to prioritise product improvements.

When I worked for Motorola’s European phone division in the 1990’s, I noticed that most of our money came from 14 customers. So, I convinced senior management to reorganise most of our people into teams, which then focused on these top customers.

My advice: If you can find structural features in a wicked problem, or its solution, then you can focus your resources better. Focus on the best or worst customers, the best or worst staff, … or products or countries or factories...

Understanding what to focus on helps you to see what sort of potential decisions you might be able to make with some data analytics. Which in turn helps you define the analytical objectives, the tools and the datasets that you need for the analysis.

2. Use time itself as a structural feature

Whoa! Sounds a bit philosophical, but wicked problems are produced by complex systems. And complex systems do not just sit there doing nothing. They are always doing something: changing, moving, developing, getting better or getting worse in some way.

According to the Greek philosopher Heraclitus, you cannot step into the same river twice (that definitely was philosophical). Unless it’s a lake.

But even lake water circulates, churns, evaporates, warms, and cools. There are always processes going on.

It’s the same with customers churning, or staff leaving and joining. Or competitors innovating, technology advancing, regulations updating, fashions moving on, and market tastes evolving.

Nothing stands still, and with wicked problems you can take advantage of that.

Movement and development processes also have structures. When we recognise them we call them phases or stages.

Stages are the structural building blocks of processes. And time series data shows us their pattern. Which gives us two opportunities to solve wicked problems:

The first is to use the structure of the problem process to experiment.

Have you ever heard the phrase ‘I’ll cross that bridge when I come to it?

You do not have to solve wicked problems in one go. You can experiment. You do not have to get it perfectly right first time.

For example, the whole idea of the Minimum Viable Product approach is to produce a good enough experimental product or service, so it generates excellent feedback data. Feedback data you can use to improve the product.

Tim Allen called them ‘course corrections’ in his great book on complex systems. A rocket to the moon does not have to be totally accurate from the start. It can make course corrections.

The second example of how to take advantage of a series of unfolding stages – a delay – is to use Real Options. Real Options are a real-world version of financial options, they buy you a chance to stay in the game and learn more about an uncertain situation.

Small pilot projects are an example of real options. They enable you to build capabilities and test your ideas. Spending money on sophisticated simulations, like the digital twin of a whole new factory, is another example of a real option.

Real Options use the structure of a timeline of events to break your company’s investments into multistage decisions, rather than one big bet.

My advice: Try and map out the process of how the complex system causes wicked problems. Look for relatively separate stages. How can you take advantage of each stage?

3. It’s you that makes it complex! – make decisions in a different way

I get this a lot at home ??. Apparently, I sometimes make a merely complicated problem into a complex problem.

It works like this: the difference between ‘complicated’ and ‘complex’ is that complex problems have lots of links between their parts. Complicated problems have lots of parts but few links.

Complicated problems don’t have many links, so you can either divide them up into smaller problems. Or you can solve them without worrying that their requirements will change in different situations.

As always, it is the links that you need to find and cut before you can divide a big problem into smaller problems. 

Ironically, the biggest source of links is your own brain. Your brain generates links in the form of dependencies.

Dependencies are the things which mean you have to have different solutions for different situations. Like when a solution depends on X and Y and Z.

Situational dependencies make potential solutions multiply until they are unmanageable.

The more you can imagine the what-ifs, the permutations, the potential problems, and the implications, then the more complexity you will generate.

Eventually, you will generate so many possibilities that you get information overload. Which is scary, because you might get so overloaded that you fail to notice that you are missing things and making mistakes.

The way to break the links between a problem and an unmanageable list of solutions is to look for another kind of structure. This time you must try and find structure in the ‘problem-solution space’.

Problems and solutions are part of the same system. If they weren't, then they would not fit together. 

Also, problems frequently have more than one solution – that’s what makes it difficult to choose between them.

Finally, solutions can solve more than one problem. Ever hear of the phrase ‘kill two birds with one stone’?

Product designers solve more than one problem at the same time when they pick a material with more than one useful quality.

Software developers also do it. When they pick a coding strategy which executes in a particular way – like when code is algorithmically efficient, or inherently secure.

My advice: look for a structure in ‘problem-solution space’.

What I mean is, try to cut the links (the dependencies) between a solution and the situations that it might be needed in – try and design a ‘vanilla’ solution. Then worry about modifying it for local situations later.

This is a bit like Suggestion #2 because it uses delays to buy time. But these are stages in your solution development process, not stages in the process which produces the problem.

You can see vanilla solutions all the time in product designs, computer science and business process mapping. It’s called a ‘modular design’. It was the main driver of the success of the original IBM PC and has made Lego into a very successful company.

A vanilla solution is the core of a solution, the thing which solves the core of the problem. You need to separate the vanilla solution from how it needs to be customised in local implementations.

Like the colour of a car is not integral to the car design, so engineers don’t need to worry too much about choosing colours. Or like how the way that a car is delivered to a customer does not affect its engineering. Although where it is sold might affect its engineering because of local emissions legislation.

Or it might be like my favourite example. Did you ever buy a cheap car with what looks like a button on the dashboard? But it’s not a button. It’s a moulded dummy button, not a real one. For cheaper cars, the designer just adds a dummy button rather than changing the whole dashboard. The core dashboard solution is 'de-coupled' – unlinked – from the different versions of the car design.

Vanilla solutions should solve the core part of a problem and nothing else. Keep them focused. Then complete the solution for each local situation by adding a local level or stage to it.

Duncan is a lecturer at Nottingham University Business School. He also advises organisations on creating value with digital data and he writes in his own blog.

Connect with me on LinkedIn at www.dhirubhai.net/in/duncan-r-shaw-7717538.