Next month:
November 2009

October 2009

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.

510aHgNxrAL._SL500_AA300_



 


 


'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.

510aHgNxrAL._SL500_AA300_

 


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. 

 

 Fishbone2

 

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.

 5-whys-lean-manufacturing-example

 

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:


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.