 |
Want to boost your performance? Embed formal
problem solving into your organisation at all levels.
Then sit back and watch performance take off! |
I
touched on problem solving as an essential skill within sustainable
organisations in an earlier post, and will now share with you the details of
the individual steps required when formally solving problems. What follows
largely applies to the industrial environment, but the principles really apply
anywhere. It would be useful to review these steps in conjunction with the
diagram in my previous post on the subject.
There
are many root cause analysis and problem solving techniques available, but what
I find is that in rushing to use these, we often lose sight of the fundamental
process of problem solving. If you use what follows in a disciplined manner,
you will find that the process of problem solving becomes simpler, and that
achievement of concrete results is facilitated.
The individual steps that I consider essential and their relevance are outlined in detail below. Each of these can be
significantly expanded upon – I may do this in future posts if there are
specific questions regarding them, but there is sufficient information below for you to make a start.
Problem
Detection
An
undetected problem will forever remain an unsolved problem, and it is vital
that problems are detected promptly. The speed with which problems are detected
is often a function of how well-organised the performance-monitoring apparatus
of an organisation is functioning.
Given
that problems are essentially gaps between desired and actual performance,
systems should be in place to track key performance indicators for all
processes considered to be important. The nature of these systems and the
frequency with which they are used is largely determined by the type of process
being monitored. An issue such as staff turnover will have a very different
type of system to one which monitors manufacturing costs, for example.
Assessment
of Problem Complexity
At
this stage of the PS process, we are interested in confirming that the problem
does indeed exist (e.g. are there measurement issues?), and also in gathering
important preliminary information that will allow us to frame the problem
accurately. Examples of the types of questions we would ask at this stage would
be:
- When does
this problem occur?
- How big is
the gap between desired and actual performance?
- Which
specific products are affected?
- Has this
problem happened before?
- What has
changed?
- Etc?
Compilation
of the Problem Statement
With
the information above in hand, we are now able to succinctly state what the
precise problem is that we intend to solve. This is a vital step in the PS
process, since it sets the scene for the entire problem solving event. Problem
statements should:
- Use clear and
simple language;
- Contain
specific facts;
- Be short and
to the point;
- Refer to the
problem only, NOT solutions;
- Focus on one
specific problem.
Lack
of attention to detail here can misdirect the process, increase the time from
detection to solution and cost money, so it is always worthwhile to invest time
in getting this right.
Identification
of Potential Causes
Every
problem can always have more than one potential cause, and this step is about
using the information at hand to identify all potential causes of the problem.
Techniques such as brainstorming, mind-mapping, Cause-and-Effects Analysis and
Why-Why networks are just some of the many available tools one could use to
identify potential causes. This step of the process relies very heavily on the business/technical skills of those
solving the problem (so-called “subject-matter expertise”). Knowledge of problem solving techniques means little in the absence of the technical knowledge relevant to the
specific problem at hand.
Determination
of the Root Cause of the Problem
The
root cause of the problem will lie among the potential causes identified and
its identification relies heavily on the gathering of irrefutable evidence,
gathered at the site of the problem as well as upstream and downstream of the
problem location.
Revision
of the Problem Statement based on Identified Root Cause
In
much the same way as the original Problem Statement guided the identification
of the root cause of the problem, revision of the Problem Statement after
identification of the root cause guides the development of solutions to the
problem. This is best illustrated through an example:
Problem detected
|
Bearing failures on mixing vessel
causing
excessive downtime
|
Original Problem statement
|
Mixing vessel bearings fail
every 3 months
|
Identified Root cause
|
Dust from powders being
mixed entering bearings
|
Revised problem statement
|
Dust entering the mixing
vessel bearings is causing premature failure
|
It
is clear from the above how a revision of the problem statement focuses the
solution development process on eliminating the dust problem. This is a more
detailed account of the problem that has to be solved. Premature bearing
failures could come about due to manufacturing defects, a lack of lubrication,
use of the incorrect lubricants, operation of the mixers outside of design
parameters and other reasons. All of these would have been eliminated during
the identification of the root cause of the problem, and can now be discarded
in developing appropriate solutions.
Identification
of Potential Solutions
Solutions
may encompass technology, work practices, management systems, engagement with
stakeholders (e.g. alternative suppliers) and changes in materials, to name a
few examples. An individual solution may incorporate a number of these issues.
It is therefore important to keep an open mind in the determination of the
various possible solutions to a particular problem. Once these solutions have
been identified, the best one can be chosen.
Selection
of the Best Solution
Selection
of the most appropriate solution is carried out by specifying the criteria that
solutions need to satisfy, and then scoring each individual solution against
those criteria. Some criteria can be non-negotiable (i.e. if a solution does
not meet it, that solution cannot be accepted) while others may be scored on a
defined scale e.g. 1= poor, 2 = acceptable, 3 = excellent. The criteria can be
assigned weights, and the final score would then reflect which solution scores
highest AND meets all non-negotiable criteria.
Typical
criteria could include:
·
Cost of the
solution;
·
Robustness;
·
Time to
implement;
·
Availability
of local support;
·
Etc.
The
selection of a solution is ultimately a judgement process, and despite this
attempt to better quantify the benefits of individual solutions, ultimately
there will intangibles that would need to be factored into the final decision.
These apply particularly where two solutions score very closely.
Planning
and Implementation of Solutions
Depending
on the scale of the solution, these activities can range from changing the
set point of an automated process to a full-scale engineering project. It is
important to remember that no matter how simple or complicated a solution is,
its success will always depend on the people who operate and maintain it. During
planning and solution implementation, involve all affected stakeholders, many
of whom will already have been involved during the problem solving process.
Ensure
also that, since in implementing a solution you are introducing a change, the
relevant change control interventions (involves systems) and change management activities (involves people)
are in place. This again depends on the scope of the solution, and could
include:
- Updating of documentation
such as engineering drawings, work instructions and maintenance schedules;
- Purchasing of
necessary spares;
- Training of
affected staff;
- Performance
monitoring systems;
- Updates to
budgets.
The
idea is to ensure that once implemented, the solution is seamlessly integrated
into your operations.
Evaluation
of Solution Effectiveness
An
effective solution:
- Addresses the
root cause of the problem, preventing its recurrence;
- Does not
introduce unintended consequences;
- Meets the
criteria upon which its selection was based once it is put into operation.
A
solution may need to be in operation for a period of time before its
effectiveness can be evaluated, particularly with respect to unintended
consequences.
Where
solutions are shown to be effective, the problem solving process is complete.
Where a solution is not effective, additional problem solving may be necessary.
The reasons behind the lack of effectiveness will have to be determined by
revisiting specific aspects of the PS process, as indicated in the flow diagram in my original post.
Summary
In
summary then, do not allow yourself to become enamoured by the plethora of
problem solving tools and techniques available without giving due consideration
to the over-arching process within which these tools are to be deployed. Spend
sufficient time defining the problem upfront – this is the foundation for the
efforts that follow. Ensure that the skills of the team are appropriate in
terms of the subject matter expertise required. Problem solving techniques
without this knowledge can only get you part of the way - you need deep
business knowledge as well. Once the root cause of the problem has been
determined, re-focus the process by revising your original problem statement.
Develop as many solutions as possible; you can never have too many potential
solutions. Choose a solution based on a detailed comparative analysis, and
where two solutions are close in terms of their score, use your professional
judgement to separate them. Plan and implement solutions with people in mind,
and always conduct a formal evaluation of the implemented solution once
sufficient time has elapsed. Revisit the problem solving process when implemented
solutions are not effective, and repeat necessary steps in this process until
an effective solution has been implemented. This last step is in line with the
PDCA cycle, and does not represent failure, but is a normal part of the PS
process.
