UNDERSTANDING THE STEPS IN THE PROBLEM SOLVING PROCESS

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.