Alan Barker

How to Solve Almost Any Problem: early reviews

How to Solve Almost Any Problem is beginning to garner reviews; and so far, they've been good.

Here, for starters, is the review in the October issue of Elite Business, an online magazine.  (Go to page 14.)  (Thanks to Scott English for allowing me to reproduce this review here.)

 

And here's the review in the September issue of Start Your Business.

I'll add further reviews to this page as they arrive.

The book now also has five Amazon reviews:  you can access them here.

Surfing the waterfall: a new approach to planning

Planning is the process of preparing, making and managing change.  We’re here, now; and we want to be somewhere else, at some point in the future.  So we can ask four questions.

• Where are we?
• Where do we want to be?
• How could we get there?
• What limits our options? 

We use plans to create new things: a cake, a new product, a work of art.  So the first question might be: what do I want to create?  The more clearly we can answer that question, the clearer the plan. 

So what makes for a clear goal?  If we’re solving a mathematical equation, the goal is a checkable correct answer.  But plans in real life tend not to be right or wrong.  They tend to be acceptable or not acceptable.  How good is the cake?  Do our customers like the new product?  Does a glass of water on a shelf in a gallery count as a work of art? 

(Michael Craig Martin: An Oak Tree, 1973.)

The next step is to construct a route from where you are to where you want to be.  The plan you create is the set of operators that will help you achieve your goal.

The standard advice is to work backwards.  Most of us, say the experts, plan forwards: we begin by identifying the first step.  Instead (they say), start at the goal and look back.  Map out the milestones you need to reach, and measure your progress against them.

The result of this approach is the ‘waterfall model’: a neat, linear sequence of stages, each of which should be completed before we embark on the next.

The model originated in manufacturing and construction: sectors where changing the sequence of operations can be prohibitively expensive.  The waterfall has become a fairly standard model for projects in other fields.  Every time you see a Gannt chart on a project manager’s wall, you’re looking at a waterfall.

The question is: does the model work?

It’s a question of context. 

Think back to that mathematical equation.  You’re operating in a closed system:  all the parameters are clear, checkable and stable.  (Imagine being told midway through your work that the number base has changed from ten to – say – eight.) 

When you’re planning in a more-or-less closed system – an assembly plant, a structured administrative process – the waterfall model will work, more or less.  Open up the system – introduce dynamic factors or multiple stakeholders, each with a different view of how the system operates – and the plan is very unlikely to follow a neat linear progression. 

So do we abandon the waterfall method?  Well, no.  Not entirely.  But we need another model to complement it.

Here’s another model.  Think about it.  In fact, don’t think about it.  Do it.

You’ll need a blank piece of paper – at least A4 size would be good – and your wallet or purse.  Put the blank piece of paper on the table and look at it. 

Go ahead: look at the paper for at least 15 seconds.  It’s blank.  Let it be blank.  There’s nothing wrong with a blank piece of paper.

Now take everything out of your wallet or purse.  Credit cards, photographs, old tickets or cash machine printouts; paper money and coins.  You’ll need at least ten objects.

You’re going to make an assemblage on the blank piece of paper, using the objects from your wallet or purse.  You can use only the objects you have, but you don’t have to use all of them.  You have three minutes. (Use a stopwatch or your wristwatch to measure the time; you’re not allowed to go past the three-minute mark.) 

Don’t read on until you’ve completed the task.

Ready?

Go!

 

(Thanks to Robert Fritz for this idea.  His book, Creating, is a source of constant inspiration.)

 

 

Now: did you follow the waterfall model? 

My guess is that you were almost certainly not planning backwards from a goal.  Instead, you were negotiating in your mind between a vague idea of what you wanted to achieve, and what you could do.  The gap between the two creates a tension that you tried to resolve by taking action.

It’s called ‘opportunity-led thinking’.  And it’s not entirely rational. We look for opportunities to create a solution. We create possible solutions and see how they might work.  We then adjust our search for opportunities based on what we found.  We’re looking for the places where we can make headway: backing up when an opportunity leads to a dead end, pushing forwards when it promises help. 

The resulting activity can look pretty chaotic.  But in fact it’s very well organized: we’re making opportunity-led switches of attention between our vision and current reality: between what we want and what we’ve got.

Planning in open systems demands opportunity-led thinking.  The key factor, often, is people.  If we’re planning a solution that involves users, customers or colleagues, then we shall need to accommodate some opportunity-led thinking.

Easier said than done, of course.  Imagine you’re a project leader:  you’re responsible for keeping the project to time and within budget.  If the project fails to meet all the requirements in the brief, you’ll be accountable.  You know that the process will – must – include opportunity-led thinking; but you must still make plans, create schedules and commit to milestones.

The key is to recognize when such thinking is necessary and to manage it dynamically.  The control we need is the control of a surfer, balancing forces and looking for the way forward.

So opportunity-led planning is like - well - surfing a waterfall.

This post is based on material from my book, How to Solve Almost Any Problem.

   

 

Why people don't change their behaviour

Discovered today: an interesting note on influencing skills.

People do what they do because that's what they know how to do, and because it has worked for them in the  past.  Thus, for people to stop what they are doing, their current behavior patterns must first be disconfirmed.  They must conclude that their current behavior no longer serves them well.

In this same vein, it is absolutely crucial to recognize that people don't oppose change because some new state of affairs promises to be worse than an existing one.  Instead, they oppose change because the existing situation is known and certain, whereas the new situation is unknown and uncertain.

No one knows what the future holds.  It might be better, it might be worse.  When people are asked to change, they're typically asked to swap a sure thing for a maybe, a known for an unknown.  Most people are reluctant to make such a trade -- except when current conditions are seen as so bad that anything else must be better.

These words are by Fred Nickols, whose work on problem solving is thorough, sensible, and inspiring. He should be much better known.

Fred has generously posted a huge amount of useful material on his website.

Google his name or go straight here to find out more.

'How to' #2: shifting perspective

In this posting, we look at a powerful way of extending the 'How to' technique to generate even more insights.

We can shift perspective on a problem by asking four possible questions.  The answers to these four questions will generate new 'How to' statements, all of different kinds.  And each question allows us to shift our perspective on the problem - to look at it in new ways.

 

There are many other ways of shifting perspective on a problem, of course.  For example, we could look at:

• functional aspects (design; production; administration)
• different points of view (management; technical; customer)
• causes of the problem

Any of these can become new 'How to' statements. Record them all on sticky notes.

 Once you are done, sort the stickies into clusters.  The categories for clustering will normally emerge as you do the sorting; try to avoid imposing artificial categories.

If you are working in a group, ask the problem owner - the person who submitted the original 'How to' - to choose a new 'How to' on the basis of:

• intrigue; and
• desire.

'Intrigue' means that the new 'How to' statement excites them and is not obviously feasible. (Feasible ideas could be put to one side to consider later.)

And 'desire' means that the new 'How to' expresses what the problem-owner really wants to happen.

Once the new 'How to' statement is chosen, the 'How to' session is over. You can move on to begin thinking about how to achieve the task.  One simple way to begin doing that is to construct 'How about' statements: ideas about possible courses of action that you could take.

'How to' is a technique for exploring problems - not for solving them.  It's a first-stage thinking technique.  Our ability to solve a problem is directly related to our perception of it.  Thus, the more richly we are able to look at a problem, the more possibilities arise for tackling it.

Find out more in my book, How to Solve Almost Any Problem.

How to 'How to' #1

In my last post, I introduced ‘How to’, a powerful technique for defining a problem and moving forward from it.

Here's how I operate the technique with a problem-solving group.

‘How to’ works best in two steps.

·        Step one.  Generate lots of ‘How to’ statements.

·        Step two.  Ask the problem owner to choose one.

Sometimes, it’s difficult for the problem owner to think of different ‘How to’ statements.  This is where the rest of the group can help.  If the problem owner remains stuck, ask:

Can we state the problem in another way? 

Is there another way of saying this? 

Do any other ‘How to’s suggest themselves?

Before long, the flipchart will be covered in ‘How to’ statements: new ways of defining or looking at the problem.  We are opening up our thinking about the problem.

Choosing a single ‘How to’ statement helps the problem owner to focus their thinking again.  They must decide what it is that they want to achieve.  The ‘How to’ statement that they choose must make sense to them logically and emotionally.  It must be within their sphere of authority and competence.  It must be an objective that they feel they can commit to. 

The aim of the ‘How to’ technique is to increase the problem owner’s sense of responsibility for tackling the problem.

Here’s an example from a training session for team leaders.  One of the group’s most persistent and frustrating problems was the failure of their briefings.  Typical comments were: “They just won’t listen”; “they’re not interested”; “they bother me with dozens of questions afterwards, even though the brief answered them all”.

Our first ‘How to’ was: “How to make team briefings more effective”.

This rapidly expanded to include:

How to make my team listen

How to present the brief more interestingly

How to make team briefings more interesting

How to stop people asking stupid questions at the end of the brief

How to handle team member’s concerns more effectively

How to change the format of the brief

How to talk with my team rather than at them

How to turn the briefing into a more meaningful meeting

How to involve the team more

In all, we generated over seventy new statements.  The result was a rich set of ideas for transforming team briefings into more interactive and productive meetings.

There's more to say about this powerful technique. Watch this space. 

You can find out more in my book, How to Solve Almost Any Problem.

 

 

'How to': a powerful problem-solving technique

I was referring the other day to fishbone diagrams, and my difficulties with them.

I ended the posting by suggesting that fishbones don't help to define the problem.

So what is available to do that job?

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

You're stuck.

And a solution is any course of action that 'unsticks' you.  It's not a 'fix', or an object.  It's something you do.

Here's a technique that I find enormously powerful for getting 'unstuck'.  You can use it in a range of ways to unlock your own creativity, and that of others.

 How to ‘How to’

State the problem as a phrase beginning with the words ‘How to’.

That's it. No other rules apply.

'How to’ helps us to look at problems in new ways.  In particular, it magically transforms problems from obstacles into goals. 

The upmarket name for this technique is ‘goal orientation’.  ‘How to’ frames a problem as a goal.  The moment you state a problem as a ‘How to’ statement, you must start to look at it as an objective.  Once you have started to look at the problem in that way, you can begin to work out how you might go about solving it.

The ‘How to’ technique starts with two assumptions.

·         Somebody owns the problem.

·         They are stuck.

Let’s look at these two important pre-conditions.

 

Owning the problem

The first step in solving any problem is to take ownership of it.  Problems without owners tend to become problems without solutions.

‘How to’ encourages us to take ownership of a problem.  It’s difficult to express the problem as a ‘How to’ statement and not take responsibility for it.  The moment we start to use ‘How to’, we are impelled to state the problem in such a way that we can feel responsible for it.

Sometimes, simply taking this first step makes problems fade away.  Once we realize that ‘it’s not my problem’, we rest easy.  And, if it remains our problem, we have begun to feel responsible for it.  We have become a ‘problem owner’.

 

Being stuck

So you need to be clear who owns the problem. But why is the problem owner stuck?

Because they are looking at the problem in only one way.

All of our thinking begins with assumptions.  If we don’t challenge them, they become fixed into a mindset.  It’s the mindset that makes us stuck.  To come unstuck, we need to break out of the mindset. 

You could think of the mindset as a hole that you are digging.  Being stuck in the mindset is like digging the same hole deeper.  Breaking out of the mindset is like escaping from the hole and finding a different place to dig.  That’s why this kind of thinking is called ‘lateral’: it helps us move sideways instead of vertically.

‘How to’ helps us to break the mindset.  By looking at the problem in a different way, the problem owner can begin to think of different ways of tackling it.

 

Imagine you’re stuck in the mud in your car.  Your first stab at a solution is to see if the car will move.  You put your foot on the accelerator.  The wheels spin uselessly.  Now what do you do?  If you keep trying the move the car, you’ll only make matters worse.  Instead, you need to look at the problem in another way. 

Do a ‘How to’: “how to make the car move”.  At once, alternative ‘how to’ statements begin to suggest themselves.

How to move the car.

How to stop the wheels spinning.

How to get a grip.

How to shift the car in another direction.

How to stop getting annoyed.

How to think of another solution.

The key is to generate as many new ‘How to’ statements as possible.  This ‘unsticks’ our thinking.  Once ‘unstuck’, we can begin to find solutions: courses of action that we might take.

In a future posting, I shall develop this technique and suggest variations.

You can find out more in my book, How to Solve Almost Any Problem.

 

Why do fishbone diagrams bother me?

Why do fishbone diagrams bother me?

 

I’m observing a training session on problem-solving in – let’s say, a large bank.  The session focuses on two techniques: the fishbone diagram and the ‘5 Whys’.  As far as this session is concerned, problem-solving more or less is drawing fishbones and asking ‘Why?’.

 

And my heart sinks.

 

Most of us probably know the basics of fishbone analysis.  If you’d like a quick reminder, there’s a good explanation here.  The technique was developed by Professor Kaoru Ishikawa in the 1960s, in the context of the Total Quality movement. 

 

 

 

The ‘5 Whys’ technique seems to have no named inventor.  I suspect that it’s a part of a kind of ‘folk wisdom’ that has grown up, perhaps particularly among engineers.  In this session, we are encouraged to take one of the problems identified on our fishbones and ask ‘Why?’ five times, in order to find the problem’s root cause.

 

 

Both techniques are promoted vigorously.  A very brief Googlesearch threw up references to both techniques in both education and the NHS.  And here they are again, in a bank.  They are clearly very popular – at least, among trainers.

 

So why do these techniques make me so uncomfortable?  As I watch the group struggle with them, a number of thoughts come to mind.

 

• The techniques are easily misunderstood.

 

To begin with, it seems hard for people to grasp that these are first-stage thinking techniques: ways of exploring potential causes of a problem rather than actual ones.  The very mechanism of looking for causes suggests that the technique will provide answers, rather than insights.

 

What categories do we pick for the ‘ribs’ of the diagram?  The question often arises, and it’s a powerful one.  When a group asks that question, they are intuitively recognizing that their answers will depend on the way they frame the search.  But the choice of categories is rarely discussed.

 

Then there is the difficulty in making sense of the diagram once it’s drawn.  In particular, the group should be looking for possible linkages between elements on the diagram.  Very rarely does the exercise progress to this point. 

 

As a result of these misunderstandings, a group can come to feel simply overwhelmed by the sheer scale of a problem.  Which is precisely what happens during this session.

 

• The techniques ignore circles of influence.

 

Both the fishbone and ‘5 Whys’ tend to drag a group’s thinking very quickly out of their circle of influence.  Effective problem-solving must surely help a group focus on what they are able to achieve; yet both techniques tend to encourage a group to think further away  from the area where it can actually make a difference.

 

• The techniques tend to evoke blame.

 

Looking for causes nearly always evokes an emotional response. 

 

If a problem involves people, it’s very hard to separate a cause from the idea of blame.  In this mindset, a problem is a bad situation, something that shouldn’t have happened – and for which someone should be punished. 

 

I think blame is a very interesting psychological phenomenon, worthy of its own posting; but for the moment, it’s important to point out that blame isn’t helpful when we are trying to solve a problem. 

 

Blame reinforces the problem as a problem; it focuses our thinking outside our circle of influence; and – like all strong emotions – it more or less disables our ability to think constructively.

 

• The techniques work on the assumption that any problem has a cause (or set of causes).

 

In fact, very few problems have clear causes.  It makes sense to use a fishbone diagrams – or to ask ‘Why?’ five times – when we want to refine or improve the performance of an otherwise stable system (such as the manufacturing processes within which the techniques were originally developed).  In most problem-solving situations, however, we aren’t trying to restore previous conditions or improve a system.  We’re trying to do something else.

 

Focussing on causes, it seems to me, is usually counterproductive in problem-solving (just as it often is in therapy).  Finding out why you are in prison doesn’t necessarily help you escape.

 

It’s not the tools’ fault.  But if a problem-solving training session focuses exclusively on techniques to remove causes, it short-changes the group and may even do damage. 

To quote (perhaps) Abraham Maslow:

"If the only tool you have is a hammer, you tend to see every problem as a nail."

 

The first rule of problem-solving is that a problem is as it is because we see it that way. 

 

Effective problem-solving should surely begin by exploring what it means to define a problem.  And, however effective these two techniques may be, neither of them do that.