Let’s recap what we’ve learnt so far about our skills as problem-solvers. Armed with your knowledge and new skills, you can begin to look at different types of problem, using a systematic method.

Problem-solving: the story so far

Here are the main points we’ve covered thus far in the book.

Having a problem means being stuck

You know you’ve got a problem when you want to do something, but you don’t know what to do.

Most problem-solving is intuitive

We match information from our experience to mental patterns, either inherited or learned. The pattern-match tells us what to do.

When intuitive problem-solving breaks down, problem-solving becomes a task with two stages

We notice that we have a problem only when this pattern-matching fails to tell us what to do. When this happens, and we become stuck, the intuitive pattern-matching approach splits into two stages: Stage 1, at which we examine and identify the problem; and Stage 2, where we decide what to do.

We can use both intuitive and rational problem-solving to solve problems

Intuitive problem-solving can help us look at problems in different ways, by reframing and switching contexts. Rational problem-solving uses reasoning, logic and evaluation to examine the situation, gather evidence, challenge our mental models, identify options for action and work out what to do.

Intuitive problem-solving and rational problem-solving operate in a close and sometimes challenging relationship. We can solve problems intuitively without engaging in rational problem-solving, but rational problem-solving cannot operate without some intuitive input. All thinking is based on assumptions, and assumptions – by definition – are intuitive. Indeed, one of the most important parts of rational problem-solving is challenging the assumptions with which we view a problem.

Four sets of skills help us solve problems

At Stage 1, the Explorer and Analyst styles help us identify the problem. The Explorer style helps us intuitively to see a problem more richly, and the Analyst style helps us rationally to understand it more accurately and objectively.

At Stage 2, the Engineer and Designer styles help us to decide what to do: the Engineer style by helping us construct feasible solutions, and the Designer style by helping us create more elegant ones.

Ownership of a problem can take two forms

• Responsibility is problem ownership conferred on us by others: they, not we, are responsible for the form of the problem, the restraints and constraints that govern it and our authority to deal with it.
• Commitment is full, unconditional ownership of a problem; we are entirely free to define the problem and to manage how we deal with it.

We can divide all problems into presented problems and constructed problems

A problem becomes a presented problem if we express it as a statement of what’s wrong:

The car won’t start.

Sales are down this quarter.

Students are profoundly disengaged from the learning process.

A problem becomes a constructed problem if we express it as a phrase beginning with the words ‘how to’:

How to start the car.

How to improve sales next quarter.

How to engage students’ interest in learning.

Constructed problems	Presented problems
‘What do I want to achieve?’	‘What’s wrong?’
Made by us	Happen to us
We are responsible for creating them	Not our ‘fault’ but we are responsible for solving them
The reason for taking the journey	Obstacle in our path
Perceived gap: what is/what could be	Perceived gap: what is/what should be
Cause creative tension	Cause stress
Solution: dispel tension by releasing energy	Solution: fight or flight
Examples:	Examples:
Gaining a qualification	The photocopier breaking down
Improving quality	A new product invading our market
Working out a strategy	Being stuck in a traffic jam
Innovating a new product or service	Delays in a production process
Increasing market share

The really important point here is that a problem is either presented or constructed because we see it that way. The terms are distinctions of definition, not of objective truth. The only real distinction between a presented and a constructed problem is in the way we express it.

And that means we can change the way we look at a problem.

In fact, presented and constructed problems often morph into each other. How often have you committed excitedly to the new challenge of a constructed problem (‘I can do that!’), only to find within a few days that you’re stressed out facing a mountain of presented problems. Perhaps, less obviously, the transformation can happen in the other direction. You may have been presented with an onerous task, only to find that it grows, as you become more interested, into an intriguing challenge.

Well-structured and ill-structured problems

So far, then, we’ve distinguished problems as presented or constructed. Another way to distinguish them is in terms of their structure.

We can define a problem’s structure by looking at four key elements:

1. initial conditions (where we are);
2. goal conditions (where we want to be);
3. operators (the different ways in which we can get from initial conditions to goal conditions);
4. constraints (whatever limits our action).

If a problem’s four elements are clear to us, we can call the problem well structured. If one or more of the elements is unclear, the problem becomes ill structured.

Well-structured problems

Solving a jigsaw puzzle is a good example of a well-structured problem:

• Initial conditions are clear. (All the pieces are jumbled up in the box.)
• Goal conditions are clear. (The lid of the box shows the finished picture.)
• Operators are clear. (Sort the pieces, find straight edges and corners, solve small areas of the puzzle and link them together ...)
• Constraints are clear. (There is only one correct arrangement of the pieces; no cutting or folding the pieces; no colouring of the pieces; no substituting pieces from another puzzle ...)

It’s hard, in theory, to imagine how we could get seriously stuck solving a jigsaw puzzle. As long as all four elements remain clear, we should be able to solve the problem by simply applying the operators for as long as it takes.

Of course, in reality we can get stuck doing a jigsaw. When that happens, we can usually determine how the problem has become ill structured by investigating the four key structural elements of the problem. Perhaps we have too many pieces of the same colour, or we don’t know whether some pieces are missing (initial conditions less clear); perhaps we’ve lost the box lid carrying the picture (goal conditions less clear). Perhaps there is some trick in the jigsaw’s design that frustrates our operators: the puzzle is circular and has a border of one colour; the edges of the puzzle are not smooth but shaped exactly like the interlocking pegs of internal pieces ...

Ill-structured problems

Deciding where to go out for the day is a good example of an ill-structured problem. Initial conditions are probably more or less clear: you know where you are at the moment, and your current circumstances don’t count as a day out. (But think about it: could you somehow transform your current circumstances into a day out without going out?) Goal conditions, on the other hand, are unclear: you could go anywhere for a day out.

How might you solve such a problem? You could load your partner and children into the car and just set out. On your journey, you might see a good place to have a picnic and decide to buy your food and drink nearby. You might see a theme park that would distract the children (or the partner) for a couple of hours and then decide whether to visit, on the basis of cost, time restraints and your previous experience of theme parks. And so on.

An alternative to this spontaneous, improvised solution would be to examine more closely all the structural elements of the problem except the goal conditions:

• Initial conditions. Where are we now? What’s within reach? What resources are available to us?
• Operators. What kind of transport is available? What could we use?
• Constraints. Who do we have to take? What do they like doing? What don’t they enjoy doing? Do we have to take the dog? How long have we got? How much do we want to spend? What’s the weather like?

Now we need two things: information and the ability to recognize a satisfactory solution. Gathering knowledge and fitting it to the structural elements of the problem creates a solution.

Solving an ill-structured problem, then, means increasing our ownership of the problem. We must bring the problem further into our circle of influence. As we saw in the last chapter, doing so means either:

• clarifying our responsibility; or
• becoming committed to solving the problem.

One way or another, we shall need to define the problem more clearly. And we can do that by:

• specifying more clearly any or all of the problem’s structural elements;
• gathering information about the situation; or
• looking out for a goal state that we can recognize as satisfactory.

We could imagine applying this technique to the problem of the day out. Mum lists all the structural elements of the problem; Dad is banished to the computer to gather useful information; children are asked to think up as many solutions as they can.

By a process of collaborative brainstorming, a plan is hatched.

It might just happen.

Structure and stuckness

It’s easy enough to see how an ill-structured problem creates stuckness. And stuckness, as we’ve seen, can provoke an emotional reaction or trigger the stress response. Faced with an ill-structured problem, we’re likely to resort to an intuitive solution: a ‘shot in the dark’ or a wild guess. Or we might give up and collapse into despondency or learned helplessness.

By attending to the structure of the problem, we can generate a better solution.

Some ill-structured problems can be ‘tamed’: you might be able to improve the structure of the problem by defining one or more variables more clearly. Simplifying the problem is often a viable way towards a solution. But sometimes a problem’s structure is overwhelmingly complex or ambiguous, and it can’t be ‘tamed’. As we’ll see in Chapter 7, we can call such problems ‘wicked’; and they demand more wholesale transformation.

But well-structured problems can create stuckness too. A problem may be so well structured that only one solution seems possible: and if we find that solution unacceptable – we’re stuck. (Remember the curse of the right answer, which we investigated in Chapter 1?)

If you want to find an acceptable solution to rigidly well-structured problems, you may have to deliberately loosen the problem’s structure.

• Initial conditions. Is there another way of looking at the situation? How would someone else see it?
• Goal conditions. Is the specified goal actually the only possible goal? Could you alter the measures of success or think of an alternative workable solution?
• Operators. Is this the only way to do it? How do other people do it? Are there short cuts or alternative ways of doing it?
• Constraints. What can you do that you think you can’t do? Are you certain that you must do certain things? What could you do differently? What rules can you break? What constraints don’t actually exist?

Loosening the structure of the problem like this will help you look at the problem in different ways and help you generate new solutions.

The problem matrix

We now have two ways of analysing problems:

1. presented or constructed; and
2. well structured or ill structured.

If we combine these two criteria, we can create four types of problem.

I’ve given names to each of these four problem types. I call a well-structured presented problem a puzzle, and an ill-structured presented problem a headache. Well-structured constructed problems I call plans, and ill-structured constructed problems dreams.

We can visualize these four types of problem, and the relationships between them, by placing them in a grid: what I call the problem matrix.

1. Puzzles (presented; well structured)

A puzzle is, typically, a deviation from a norm. There’s a gap between what is and what should be.

As with all presented problems, we can express a puzzle as a statement of what’s wrong. The objective in solving a puzzle is to put something right.

Puzzles are well structured. For a problem to qualify as a puzzle, the deviation from the norm must be measurable. Puzzles usually have one right answer.

Most puzzles either are, or can be seen as, technical: a fault in a machine, an interruption in the power supply, a piece of equipment that won’t work properly. The classic problem-solving process – diagnose the cause of the problem, remove the cause, solve the problem – will work only for this type of problem.

Typical examples

All of these can be puzzles: mending a piece of equipment; reconciling a set of accounts; making a process more efficient; improving productivity or personal performance in a measurable way.

What style to use?

Solving a puzzle would typically involve using the skills of the Analyst and Engineer styles.

2 Headaches (presented; ill structured)

A headache, like a puzzle, is a deviation from the norm. We can express a headache as a statement of what’s wrong; we can see a gap between what is and what should be. The aim in solving a headache is to put something right.

Unlike a puzzle, however, a headache is ill structured. We might identify a number of reasons for this lack of clarity:

• Initial conditions. We may not be able to identify a single cause of the fault, or to map the problem sufficiently accurately.
• Goal conditions. We may not be able to determine when the problem has been definitively solved. It may be unclear whether the problem has been solved once we have implemented a solution.
• Operators. We may not know how to reach the goal from our current situation; the problem may be unprecedented, so that we have no experience to draw on. Perhaps all past attempts to solve the problem have failed. Most irritatingly, seeking to solve a headache may actually intensify it – or transfer the pain somewhere else.
• Constraints. It may not be clear what we’re allowed to do, or are forbidden from doing.

Much traditional problem-solving, especially in the corporate arena, spends a lot of time and effort trying to ‘tame’ headaches – typically, by transforming them into puzzles. Taming can be a legitimate strategy. Unfortunately, headaches often have a habit of recurring – sometimes in different places (or in different heads).

Some headaches are ‘wicked’ problems. Wicked problems – as we’ll see in Chapter 7 – have specific characteristics. We may be able to deal with a wicked problem by taming it; and we may need to transform it into another type of problem: a plan or a dream. The problem will change radically if we do so – but perhaps that’s what needs to happen to make any progress.

Typical examples

Headaches are nearly always problems involving a human element. In particular, we might identify a headache as a problem involving a group of stakeholders: individuals or groups who contribute to the problem by defining it differently, and who must also be involved in any solution.

A headache can be relatively small-scale. A persistently troublesome relationship at work, for example, or a personal relationship that’s ‘on the rocks’, could both qualify as headaches. The problem could involve large numbers of people: problems with legacy IT systems – involving suppliers, users, budget-holders and even customers – are among the most common headaches currently afflicting large organizations. A headache may arise in relationships between organizations: industrial disputes and unhappy commercial contracts are usually headaches. And major social issues are often headaches: developing or preserving a local neighbourhood; reducing poverty in a city or community; achieving peace in a war zone.

What style to use?

Treating headaches nearly always requires an imaginative combination of thinking styles:

Making sense of a headache may seem to need all the skills of the Analyst style. But one of the defining features of a headache is that it cannot be entirely explained using rational methods; we may find ourselves succumbing to analysis paralysis in our efforts to understand the problem in detail.

We might turn to the Explorer style to gather more information about the problem, or to look for similar problems in different areas. Finding analogies may be a key to finding a way forward.

The Engineer style may help in breaking the problem down into manageable parts and fixing what can be fixed.

But the Designer style may well be crucial in creating a solution that is new and acceptable to all stakeholders.

3 Plans (constructed; well structured)

Plans are examples of constructed problems. We can express a plan as a phrase beginning with the words ‘how to’. A plan is a problem we set ourselves: we might call it a challenge or an ambition. Our objective in solving a plan is to create something new.

Plans are well structured. We see a measurable gap between what is and what could be; we can define or measure our progress towards the goal and the goal itself. We map out plans in terms of objectives, targets, milestones and measures of success. Any well-managed project is an example of a plan.

Typical examples

Think of these as typical plans: gaining a qualification; giving up smoking; working out objectives after an appraisal; setting a budget; building a new sports complex.

What style to use?

As with puzzles, the Analyst and Engineer styles will usually be predominant in constructing plans. All the tools and techniques of project management seek to exploit these rational styles to the full.

But the Explorer style always helps us look at aspects of the problem in new ways; and the Designer style can also be brought in to help deliver more elegant, efficient plans of action.

4 Dreams (constructed; ill structured)

A dream, like a plan, is a constructed problem. We can express it as a ‘how to’ statement. Like a plan, a dream is a problem we set ourselves: a challenge or an ambition. Our aim is to create something new.

Unlike a plan, however, a dream’s objective is unclear. Or rather, it’s only broadly clear what we want to achieve. We’re not at the point where we can set up a project to achieve our goal; rather, we have a rough notion of what we would like to achieve.

Typical examples

Dreams might include: finding a new career; innovating a new product; transforming the way we make or do something; making our school more welcoming; increasing customer satisfaction.

What style to use?

Tackling dreams begins with understanding the potential in a situation: the Explorer style will predominate over the Analyst style. Making something new always draws on the skills of the Designer style.

But making our dreams into feasible, workable solutions usually demands a healthy dose of Analyst and Engineer. The danger is that we turn to these styles of rational thinking too soon, before we’ve explored the available options.

Using the problem matrix

In the next four chapters, we’ll look at each of these types of problem in more detail. We’ll see what different skills, tools and techniques we can use to tackle each type of problem, and how each problem type generates a different type of solution.

Meanwhile, let’s remind ourselves: the only difference between these four types of problem is in the way we look at them. We can choose to see a problem as being of a certain type. Our choice of solution – the action we take – depends on how we categorize the problem.

Just as we can choose how to look at a problem, we can choose to look at a problem differently. The problem matrix can help us to see how we’re looking at a problem, and it can help us look at the problem in new ways. By moving a problem around the grid, we can transform a problem from one type to another. We might also split a problem into parts and solve each part differently.

Figure 5.1 To guide your thinking