Introduction

“A problem well stated is a problem half solved.” Charles Kettering

This resource has been compiled from various workshops on this topic.

Exercise 1

Problems I have solved

Each person tell a story about a problem they have solved (or attempted to solve.

Based on the stories identify the common approach and strategies that people use to solve the problem

Group feedback

• First you have to realise and accept that there is a problem
• Then create space to observe and reflect what’s going on
• Then gather information that relates to the problem
• Timing is important –
• To find good answers you may need to ask different questions, change perspective, look at it from a macro level, change your attitude (you can’t solve it if you’re angry)
• Do a thorough analysis needs analysis
• engage with the problem – accept that it is there and it’s not going to go away
• brain storm potential solutions, test and discard what won’t work
• Leave it to your instinct
• Be patient. Forget the solution. Once a problem is identified, resolutions become apparent. A problem described is half solved

Exercise 2

Based on the stories identify traps in the problem-solving process.

The following represent some of the traps

Forcing a solution

If you try to solve a thing before you have identified the root cause you just go in to endless loops of trying and failing If you are too anxious to solve the problem you may not be giving yourself time to see what is really wrong

The quick fix generally makes the problem worse in the long run and result in range of unintended consequences

Responding to symptoms

Treating the symptom, may not address the cause. The problem doesn't go away.

Be careful of assumptions. Often first perception of problem not true – it’s the symptom

symptom is not a cause

Letting feelings get in the way

Solving problems which involve personal relationships are the most difficult to deal with. WE may not want to accept that the other person is the source of the problem or is actively creating the problem. Our loyalty and our wish to retain friendships, our unease in confronting people results in:

• Blind spots where those people are concerned
• Denial
• Hesitation or delay in reacting

The language trap

The major thinking trap that emerges in these workshops are language traps. Or is that our language reflects our poor thinking processes?

1. The use of stand-alone nouns to represent complex issues

Words like ‘Financial management’, ‘Time’ and ‘Unemployment’ have no context and therefore they have no life. They don't take our minds anywhere. Stand-alone nouns are like butterflies pinned to a board. They look like butterflies but they aren't alive and they can't fly. Problem identification/solving is a thinking process - and processes are about movement, change, resolution...

The basis of language-based thinking is grammar. Grammar is sentences, linking together words, taking the nouns and putting them into the context, giving them a specific meaning, specific attributes, relationships with other concepts, and with verbs. The sentence we construct is what gives us movement, direction and solutions.

2. The use of the use of high-flown phrases to describe simple problems.

Some descriptions make the problem sound really fundamental and important  On probing more deeply it turned out that they were a proxy for something minor and inconsequential in the context:

3 The use of a concept to describe a problem

When the word time was challenged this following emerged:

"What do you mean by the word ‘Time’?"

"I have no time for the things I want to do for myself, my family."

"Why"

"I take on too many tasks and responsibilities, more than I can handle."

Why?

"I don't estimate the time each activity will take up of my time."

"Why?"

"I don't think before accepting or engaging in new assignments."

The series of sentences has taken us on a short journey through which we realise the problem is not about time but about planning and managing myself.

Introduction

These are some of the techniques one can use to identify the problem.

Gather information

• Listen carefully
• Observe closely
• What happened? What was the sequence of events? When did it happen? Who was there, who was involved?
• What are all the symptoms - not only results also process of going wrong, the wobbles before the collapse?
• What are the transactions here? What did you do before the person responded?
• Has the problem been seen before? What is the history? Where are the records?

Change perspective

View the problem from point-of-view of the:

• user
• customer
• participant
• CEO/MD/Minister

Why? Why? Why? (or the 5Why method)

Formulate a preliminary hypothesis or formulate a preliminary problem statement.

Then like a child repeatedly ask ‘Why?

Use the scientific approach

 Tabulate issues or data

• Make case studies
• Perform ‘before and after’ surveys
• Structured questionnaires - but not ones looking for solutions.

Quantify the issues & analyse the data

 Collect data

• Score sheet
• Customer returns
• Brain storming
• Focus groups
• Charts, graphs
• Statistical techniques
• Flow chart of events

Analyse the data

eg Indicator Matrix (Measure)

Sort information

Compile statements relating to the problem. Then:

• Separate conjecture from concrete facts
• Reduce issues to single sentence
• Collate numbers into graphs, tables etc

Scope of problem

Determine the scope of the problem

• Is it only this printer that's not working?
• I observed this in one company, classroom or school? Is this true for other companies, classrooms or school?

Visualise the problem

Metaplan - also known locally as Participlan

This is a useful technique in which you use cards and brown paper to gather, sort and structure and range of in puts to try and complete the jigsaw puzzle.

Metaplan traditionally uses pin boards and cards are pinned up.

The use of contact adhesive makes the process quicker and easier.

Compile each idea on a card – single words are dangerous: construct short sentences. see Concept to describe problem

  Problem tree

Used by development agencies for project planning purposes, especially useful when involving the participation of stakeholders.

Fish bone diagram

Developed by Dr. Kaoru Ishikawa, a Japanese quality control statistician, it is also called the Ishikawa diagram.

The fishbone diagram is a systematic way of looking at effects and the causes that create or contribute to those effects. The end result looks much like the skeleton of a fish. Therefore, it is often referred to as the fishbone diagram.

Here is a useful explanation of the method

http://www.frahme.com/fishbone.htm

It is most often used in the context of machinery and equipment and in quality management circles such as Six Sigma. Other than the so-called 4 M’s (Men, Methods, Machines, Materials), analysis points include,

• the 4 P’s (Place, Procedure, People, Policies)
• the 4 S’s: (Systems, Surroundings, Suppliers, Skills)

Clearly Men would also include Women

Other web resources :

http://quality.enr.state.nc.us/tools/fishbone.htm

http://www.isixsigma.com/dictionary/Fishbone-64.htm

Six thinking hats

Based on Edward DeBono’s book of the same title

SCRAP

Based on a technique for formulating business letters. Source not known.

Objective

Reduce the information to a problem statement - the one sentence which describes the key issue.

• Describe what the problem is or what has taken place, without criticism, condescension or sarcasm.
• Avoid using the word "you."
• "You people are poor payers" becomes "No payment has been received for the invoices we submitted in December"
• Avoid making accusations
• "Bloody labour is holding up the process again" becomes "The labour representatives weren't mandated to support that kind of decision"

Form of the problem statement

Phrase it in the form of a deficiency from the expected

• The training manuals were not there when the course started
• No unemployed learners were involved in the learnership project (vs the anticipated 50%)
• 30% of workers in the job-creation projects were formally employed one year of the project finished (vs the planned 80%)
• Education and training providers are using inappropriate learning methodologies.
• The decision-making process in the Department of X averages 40 days longer than in other government departments

Other tips

Quantify as much as you can

• 70 %/the majority/most of customers have to wait longer than 30 minutes...
• Support the problem statement with as much physical evidence as you can
• Shortly before the accident there were several strong gusts of wind.
• The figures are detailed in the annual report of the X Agency
• List all symptoms

Listen to your unconscious

Often after working with a problem and going around in circles your unconscious mind pops the correct issue into your mind while you're showering, driving to work or changing a nappy.

1. Avoid laden terms

Terms like the following are problematic:

• Computer crash
• Process blows up
• Failure

What is really meant by a term like "failure" "crash", blows"?

2. Leave Murphy alone

Attributing the problem to some outside force or describing in pseudo-objective terms focuses the attention on the wrong aspect of the problem 

• "The computer lost the file" - The issue is that you can't find the file.
• An extreme case: Worker is arrives late at the bus stop and reports the problem as being "The bus left without me."
• “It was Murphy again” (as in Murphy’s laws, what can go wrong, will.)

3. Avoid broad generalisations

Broad generalisations sometimes create problems where there aren't any?

• "Employers don't train their staff" - is it all, some, 70% or 20% of employers don't train their staff.

Separate concrete facts from conjecture.

4 Avoid conjecture

Framing the problem in terms of conjecture about underlying causes also distorts the problem.

My car needs wheel alignment ...On a flat road surface on a windless day my car pulls to the left. Wheel alignment is only one possible solution. Low tyre pressure in the left front tyre could also cause the same behaviour.

"The staff just aren't doing their work". The meeting packs were not ready  for distribution 14 days prior to the Board meeting 

"Johnny is hyperactive" He's boisterous, full of energy and lacks discipline, but clinically he's a normal four-year old.

Examples from child-care/school

5 Neutral perspective

Sometimes (not always) it's useful to use a neutral perspective

Take out the "I" or "me"

"When I want to overtake the car goes slower" When the accelerator is depressed quickly the engine bogs.

View it from the perspective of the person experiencing the problem