IRM Training - White Paper

Problem Analysis Techniques

Problem Analysis Techniques

Derrick Brown, Director
Jan Kusiak, General Manager
IRM Training Pty Ltd ABN 56 007 219 589
Suite 209, 620 St Kilda Rd, Melbourne, Vic. 3004, Australia
03 9533 2300
[email protected]
[email protected]

Introduction
This extract from IRM’s training material looks at how a structured approach to defining and
analysing problems can be used as the basis for designing better solutions. Part 1 of this paper looks
at problem definition. Part 2 introduces the reader to analytical techniques for determining the root
cause of a problem. Future papers in this series will look at creative thinking techniques for
successful solution design.

_______________________________________________________________________

1.0 Problem – what problem?

Problems come in a variety of shapes and sizes. For example, in motoring, we can use the word
‘problem’ to cover:

• A car breakdown
• High running costs
• Locking keys inside
• Too much time spent driving
• Which car to buy
• A back seat driver
• Not being able to afford a car

All these could be termed problems, yet they are very different and require different approaches to
deal with them. Some problems are short term, some are long term. Some involve decisions. Some
involve a whole range of problems from which priorities must be chosen. Some may not be
completely soluble and may have to be coped with.

There is no one way that will solve all problems. There are various approaches, or ‘tools’, which
will help to solve certain types of problems. Most of them are only ordered common sense, but this
is precisely what is lacking in many intuitive attempts to tackle problems. Analysts must be
comfortable with a number of tools and should not be afraid of trying out several on any given
problem. They are all methods that help us to think our way through the issue.

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 1

IRM Training - White Paper
Problem Analysis Techniques

1.1 Identifying priorities

Where can I
achieve the
greatest reduction?
Many problems are complex, involving a whole range of
causes. For example, suppose the problem is overspending
in a department. There may be many items of expenditure BUDGET
that make up the department budget. Some of these will be
large, others trivial. Some may be easily cut back, whilst
others cannot be reduced. By identifying which items are
capable of giving the greatest reductions, and concentrating
on them, best use may be made of the resources and time
available.

Unfortunately for us, not many problems are so easily

soluble as this example. However the principle remains – we must spend our limited time wisely.
It’s no use spending many days solving a tiny problem of little consequence when there is a big
problem to solve that demands a good solution. This principle is often expressed as the 80/20 rule.

1.2 Analysing symptoms to find causes

This is the heart of problem analysis. Before taking action, symptoms must be distinguished from
causes. Is a headache the problem, or is it a symptom of a more serious illness? Often, the absence
of a symptom may be just as significant as its presence.

Having a headache Monday to Friday, but not on Saturdays or Sundays, may give a clue to its
cause! What is wanted is a cause, or causes, that will adequately account for symptoms
experienced. Most approaches make ‘models’ or charts of the situation on which all the known
facts can be entered. From these models, the underlying pattern is deduced.

Business analysts will hear many business problems described, and many more ‘solutions’
suggested as the way to remedy the problems. While it would not be wise to ignore anything said,
we are well-advised to listen carefully and analyse any situation for ourselves before agreeing to
solutions. Quite often the solutions put forward are the immediate, obvious, knee-jerk solutions –
which are inappropriate! The business analyst must develop an independent spirit and he/she must
be prepared to argue a case with management rather than just accept instructions. The solutions
that we’re going to specify are going to be expensive and time-consuming – we’d be wise to ensure
that they’re going to work and that they are the most appropriate.

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 2

IRM Training - White Paper
Problem Analysis Techniques

1.3 Developing alternatives

In some situations the cause is known. The Solution

question is what to do about it? A good example
is locking yourself out of your car; you are not This way?
interested in why you did it. You just want to get
in. Various approaches exist for developing or this way?
alternatives, for example, Brainstorming and or this way?
Problem
Lateral Thinking. No one can be turned into an .
Einstein by these techniques, but people are .
usually more creative than they give themselves .
credit for. This inherent ability can be developed. .
What we need are options to choose from – .
there’s always another way if only we can find
it!

1.4 Decision making

Choosing between alternatives can involve:

1. Technical factors, such as costs

2. Human factors:
• Who should be involved in making the decision?
• Who needs to accept it?
3. Risk:
• How can uncertainty be allowed for?
• What can go wrong?
• What monitoring needs to be done?
• What contingency plans should be prepared?
Decision making tools available, such as Weighted Points and Decision Trees, involve setting out
the facts in a logical way so that the overall decision is made as a result of many minor ones.
Many specialised mathematical decision making techniques exist, but they are really tools of the
Operational Research specialist.

1.5 Follow up

• Having tackled the problem, what can be learned from it?

• What new procedures will help prevent similar problems in the future?

• Where decisions have been made, can we monitor their effectiveness?

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 3

IRM Training - White Paper
Problem Analysis Techniques

1.6 Golden rules

• Do not confuse an Objective with a Problem Definition. For example: ‘My problem is that I
need a website’. This could be a solution looking for a problem!
• Find out why a problem exists - don’t just accept the definition that you’re given.
• Get inside the problem - see it, experience it, understand it.
• Just like Objectives, Problems must also be quantified.

We often find that particular solutions are requested by clients – and provided by service providers.
It is always advisable to define the problem before jumping into solutions.

2.0 Analytical techniques

We will look at two specific techniques – Cause & Effect Analysis, BPR 20 questions - that may
help us in certain situations. There is no magic in these, or any, techniques. However, only by
understanding and mastering techniques can we:

a) get the most out of them

b) determine their suitability for the task at hand

2.1 Cause and effect analysis

Caused by Causes
Big Problem

Cause Cause Cause

Root Cause Cause Cause Cause

Cause

Root Root Root Root Root

Cause Cause Cause Cause Cause

This technique is most useful when analysing big problems or seemingly complicated issues
where all factors seem to be inter-related.

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 4

IRM Training - White Paper
Problem Analysis Techniques

Principle:
Problems don’t just happen (cause)
One thing leads to another (effect)

Example:
‘Systems take too long to develop’
- Is this the problem or the effect of many other problems?

The Cause and Effect Analysis tool uses a hierarchy to rationalise the factors that contribute to the
manifestation of a problem. It is a simple way of making sense out of what may be a confusing set
of inter-relating factors.

2.2 Cause & effect analysis – example 1

Hole Cargo Shift Capsize

Collision Sabotage

Bad Stowage Bad Weather

Method

• Pick one major problem

• List all those minor problems which contribute to this major problem
• Group into related sets
• Organise as an hierarchy
or
• Tabulate causes and effects using words leads to and caused by
• Quantify the causes for each effect – an estimated percentage

Note that quantification is rarely an exact science – it doesn’t need to be in this case. We use it
merely to help us to focus a little more objectively on the important factors.

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 5

IRM Training - White Paper
Problem Analysis Techniques

2.3 Cause and effect – example 2

Recruitment Difficulties

Travel Time Travel Cost Poor Image Poor Pay

40% 40% 10% 10%

Location Factory Location

100% 50% 50%

An example cause and effect analysis of the problem of recruitment experienced by an I.T. service
provider located in the rural commuter belt of a large city.

Analysing the problem using this tool exposed a fallacy in the accepted logic of advertising
nationally and offering higher pay plus flexible hours to compensate for the additional travel.

Instead, advertising was switched to local papers only, targeting commuters who were tired of the
daily travel to city centre offices.

The percentages indicate the analyst’s quantification of the contribution made by the individual
causes to those at the previous level. Though inevitably only an approximation, these can form the
basis of design decisions about which areas requires priority in devising a solution. In the above
example it was obvious which cause deserved the most thought for a good solution.

2.4 Business process re-engineering (BPR)

BPR is the name that was given in the nineties to the process of re-thinking through what a business
does, and how it does it. It takes into account all factors involved – cultural, technical, costs, skills,
outcomes. Cynics may say that good business analysis has always done this! The term BPR is
fading out of fashion in some quarters now but the principles involved are sound.
There are many tools and techniques associated with BPR but one of the most powerful that we have
experienced is the ‘Twenty questions’ tool.

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 6

IRM Training - White Paper
Problem Analysis Techniques

2.5 BPR 20 questions

Identify a process – preferably a key process within the system that you’re studying. Then question
each process as follows:

1. What is being done? (what is being achieved)

• Why is it necessary?
• What else could be done?
• What else should be done?

2. Where is it being done?

• Why there?
• Where else could it be done?
• Where else should it be done?

3. When is it done?
• Why then?
• When else could it be done?
• When else should it be done?

4. Who does it?

• Why this person/group?
• Who else could do it?
• Who else should do it?

5. How is it done?
• Why this way?
• How else could it be done?
• How else should it be done?

Note: It’s important that questions are asked in a sequence. Group 1 questions (What) are asked
first, group 5 questions are asked last. It’s not important how the other groups are asked.
There’s not so much that’s really new…

I keep six honest serving men

(They taught me all I knew)
Their names are What and Why and When
And How and Where and Who
Rudyard Kipling, Just-So Stories

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 7

IRM Training - White Paper
Problem Analysis Techniques

2.6 Example of BPR 20 questions – credit check process

1. What is being achieved? Minimising bad debts

Why is it necessary? Some customers are unable to pay for goods

What else could be done? • Payment with order

• Pay after order placed but before delivery
• COD
• Bond

What should be done? To be decided

2. Where is it being done? Stock control section

Why there? ………………………

Where else could it be done? ……………………..

………..etc

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 8

IRM Training - White Paper
Problem Analysis Techniques

2.7 Problem analysis checklist

The following checklist can be helpful in the review of problem analysis work:

1. Were any problems positively identified by managerial or supervisory staff?

2. Is there any evidence of procedural difficulty?
3. Are procedures and documentation satisfactory?
4. Is there any duplication of effort or information?
5. Are any processes redundant?
6. Does the workload exhibit peaks and troughs? If so, are these in regular cycles?
7. Are the bottlenecks in the system?
8. Are any facilities under-employed?
9. Are controls satisfactory?
10. Would auditing the system be difficult?
11. Does the system cope with exceptions?
12. Are exceptions, inaccuracies and omissions excessive?
13. Are files accurate and up-to-date? Do they need to be?
14. If files are not up-to-date, what problems does this cause?
15. Are there delays in the completion of work and in the production of information?

2.8 Information systems

The preceding examples show methods of analysing existing systems. Frequently, however, new
systems are concerned with the provision of Management Information. The analytical task then is
to determine whether the information being requested is relevant. Typical questions to be asked are:

• For what purpose is the information needed?

• How will it be interpreted?
• What decisions will be based on this information?
• Could exception reporting be used?
• What response time is necessary?
• How accurate and up-to-date must the information be?
• Is the reproduction of data for comparisons with previous periods justified?
• Is it relevant?
• Do the information requirements pass the ‘so what’ test?

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 9

IRM Training - White Paper
Problem Analysis Techniques

Let’s not forget that many systems produce more information than users can realistically use.
Users and managers also often ask for information to be made available without too much thought
as to how exactly it will be used. When we ask the right questions we may uncover more effective
processes.

2.9 Whose problem is it?

Two excellent writers on problem solving are Gerald Weinberg and Donald Gause. In their book,
‘Are Your Lights On?’, they explore the problem of problem solving in a light hearted and
entertaining style. The quotes that follow are taken from the chapter ‘Whose Problem is it?’

• Don’t solve other people’s problems when they can solve them perfectly well themselves
• If it’s their problem, make it their problem
• Don’t mistake a solution method for a problem definition
• Don’t leap to conclusions, but don’t ignore your first impression
• We never have enough time to consider if we want it, but always have time to regret it
• We never have enough time to do it right, but always have time to do it over again
• Don’t bother trying to solve problems for people without a sense of humour!!

2.10 Summary

Of course problem analysis is only half the story. The next step is to design one or a number of
potential solutions to the problem. The next paper in this series looks at techniques for creative
thinking, design methods for successful solutions and validation.

By Derrick Brown and Jan Kusiak

© 2002-2007 IRM Training Pty Ltd. All rights reserved.

Send feedback and comments to: [email protected]

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 10