Structured Problem Solving – A Practical Project Approach

Andreas Zemelka
September, 2018

Content

Scope and Purpose
Why Structured Problem Solving Is Often Not Applied
Why Projects Apply Structured Problem Solving Ineffectively
Selecting the Right Problems to Solve
Defining the Actual Problem
Selecting an Appropriate Problem-Solving Approach
Practical Conclusions

1. Purpose and Practical Context

Structured problem solving is a well-established subject, supported by numerous methodologies, tools and techniques ranging from relatively simple approaches to highly sophisticated and formalized processes.

This article does not propose a new problem-solving methodology or provide a training guide for any particular method. It presents a pragmatic approach to structured problem solving in projects, drawing on established Root Cause Analysis principles and selected tools such as Fault Tree Analysis and the 5 Whys. The emphasis is on selecting and applying suitable elements in a simple, proportionate and effective manner.

The article is primarily directed at project managers, engineers and other project team members who regularly have to deal with problems as part of their day-to-day responsibilities. It is based mainly on observations and practical experience from construction and industrial projects.

Despite the considerable technical expertise and experience typically available on such projects, problems are frequently addressed without first clearly defining and understanding the actual problem, its causes and its consequences.

As a result, significant time and resources may be spent solving the wrong problem, treating symptoms rather than causes, or implementing actions that do not resolve the actual issue.

2. Why Structured Problem Solving Is Often Not Applied

Numerous structured problem-solving methods are available, ranging from relatively simple approaches to sophisticated methodologies supported by specialized tools and software. Many engineers, managers and other professionals have also attended relevant training courses or obtained certifications.

Nevertheless, structured problem solving is frequently not applied in day-to-day project practice.

There can be many reasons for this:

The methodology is not sufficiently understood. People may have attended training but still lack the confidence or practical experience required to apply what they have learned.
The methodology appears too complex. Extensive procedures, terminology, templates and documentation can discourage project teams from using the method.
The practical application is unclear. Understanding a methodology during a training course does not necessarily mean being able to apply it effectively to a real project problem.
There is insufficient time. Project teams working under schedule pressure may perceive structured problem solving as an additional activity that delays the actual solution.
Resources are limited. The required facilitators, specialists, time or budget may simply not be available.
The project environment does not support the process. Colleagues or managers may not understand the methodology, may not see its value or may be unwilling to participate.
People may feel uncomfortable with highly formalized processes. Experienced professionals can be reluctant to participate in a process dominated by unfamiliar terminology, specialist methodologies or dedicated problem-solving experts.
Previous experience has been negative. Poorly facilitated or incorrectly applied problem-solving processes may have produced disappointing results, reinforcing the perception that structured methods are ineffective or unnecessarily complicated.

Specialized software can create an additional barrier. Tools intended to facilitate structured problem solving often require specific training and regular use to be effective. For project teams using them only occasionally, the software may create additional problems of its own. The team then has to spend time and resources solving problems associated with the software itself—problems that would not exist without the tool—while attention is diverted from the actual problem the software was intended to help solve.

Decisions are sometimes made outside the structured process. While a team is analysing a problem systematically, managers or other influential individuals may take parallel decisions based on experience, intuition or authority. The structured process then loses relevance.

The results may not receive sufficient attention. Even a well-conducted analysis provides little value if its conclusions are ignored or decisions have effectively already been made.

The technically appropriate solution may not be organizationally or “politically” acceptable. In some cases, the problem is understood and a technically reasonable solution is available, but its implementation is not desired because it conflicts with commercial interests, contractual positions, previous management decisions, responsibilities or the interests of influential stakeholders. In such situations, further technical analysis alone will not resolve the problem.

A technically solvable problem is not necessarily a problem that the project organization is willing to solve.

Limited individual recognition. Structured problem solving is a collaborative, step-by-step process, which can make individual expertise and the originator of a solution less visible.

The Result:

Under these circumstances, project teams often return to what appears to be the faster and easier alternative:

The problem is addressed spontaneously, based primarily on experience, intuition and immediate technical judgement.

Experience and expert judgement are extremely valuable and should always form part of problem solving. However, relying on them alone carries an important risk: actions may start before the actual problem has been clearly defined and understood.

This can result in:

symptoms being treated instead of root causes;
the wrong problem being addressed;
problems being only temporarily fixed;
significant resources being spent without achieving a sustainable solution; and
the actual problem continuing to affect cost, schedule, quality, safety or operation.

The challenge is therefore not to introduce more complex methodologies, but to establish a problem-solving approach that is:

simple enough for everyday project use
structured enough to be effective, and
practical enough to be accepted by the project team

3. Why Structured Problem Solving Is Sometimes Applied Ineffectively

This is different. Here, a structured process exists and is being used—but it does not produce the expected results.

Typical examples include:

The wrong problem is selected.
The problem is not properly defined before analysis starts.
Symptoms are confused with the actual problem.
Root causes are confused with contributing factors. Teams may identify and address factors that contribute to the problem without determining the underlying root cause, resulting in corrective actions that reduce symptoms but do not prevent recurrence.
The methodology is applied mechanically rather than adapted to the problem.
The selected method is unnecessarily sophisticated for the problem being addressed.
The facilitator lacks practical skills, even if formally trained or certified.
The process is poorly facilitated or becomes chaotic.
Too much attention is given to the methodology itself rather than to understanding and solving the problem.
Important people are not involved, or the wrong people participate.
Experts dominate the process, while people with relevant practical knowledge are not sufficiently heard.
Conclusions are reached before the analysis is completed.
Parallel decisions are made outside the structured process, particularly by managers or other influential individuals.
Results and recommendations are ignored.
The technically appropriate solution is organizationally, commercially or “politically” not desired.
The process becomes a formal exercise—meetings are held, forms completed and reports produced—but nobody takes ownership of the result.

4. Selecting the Right Problems to Solve

Before starting any structured problem-solving process, there is an important question to be answered:

Does the problem actually need to be solved?

Not every problem requires a solution, and not every problem that requires a solution justifies a formal or structured problem-solving process. Particularly on construction and industrial projects, time, specialist resources and management attention are limited and should be focused on the problems that really matter.

A problem may not require structured problem solving because:

It can be accepted and managed. The problem and its consequences are known and understood, and the project team knows how to live with it.

A technically solvable problem is not necessarily a problem that requires a solution.

It is not really a significant problem. Some deviations, deficiencies or inconveniences simply do not justify the effort required for further investigation.
The solution is obvious. Some problems can be resolved directly without applying a particular problem-solving methodology.
It does not need to be solved yet. The problem may be monitored and addressed later if its significance increases or circumstances change.
It may disappear as a result of other activities. A planned modification, subsequent construction activity or other development may eliminate the problem without requiring separate action.
The effort required to solve it is not justified. The cost, time or resources required may exceed the expected benefit of solving the problem.
It cannot reasonably be solved by the project team. The issue may need to be escalated, transferred to another party or simply monitored.
The problem or associated risk is consciously accepted. Management may decide to accept the situation and its consequences for commercial, schedule, operational or strategic reasons.

Categorization and Prioritization:

Instead of immediately trying to solve every problem that appears, it can therefore be useful to first identify, categorize and prioritize the relevant problems.

For each problem, the project team should decide:

Does it actually require a solution?
How important and urgent is it?
Does it need to be solved now or can it wait?
Who should be responsible for dealing with it?
What level of effort is justified?
What problem-solving method, if any, should be applied?

Not every identified problem requires or justifies a solution, and problems that do require a solution do not necessarily require the same level of effort. A simple initial screening can help determine the appropriate priority, responsibility and problem-solving approach.

Figure 1 – Example of Problem Screening and Categorization.

The complexity of the selected approach should be appropriate to the significance and complexity of the problem. A simple problem may require only a simple analysis and decision, while a complex or high-impact problem may justify a more systematic and comprehensive process.

This initial selection and prioritization is an important part of effective problem solving. Considerable time and resources can otherwise be spent investigating and solving issues that have little relevance while more important problems remain unresolved.

Problem solving can fail even when the selected methodology is applied correctly—not because the method was wrong, but because the wrong problem was selected for solving.

5. Defining the Actual Problem

Before attempting to solve a problem, the team must first ensure that the actual problem is clearly understood and correctly defined. What initially appears to be the problem may only be a symptom or consequence of a deeper issue.

A good problem definition should describe what is happening, where and when it occurs, and how significant the impact is, without prematurely assuming the cause or proposing a solution.

Solving the wrong problem efficiently still produces the wrong result.

6. Selecting an Appropriate Problem-Solving Approach

There are many structured problem-solving methods, approaches and tools, ranging from relatively simple and intuitive techniques to complex and sophisticated methodologies. Examples include:

Root Cause Analysis (RCA)
Structured Troubleshooting
5 Whys
Fault Tree Analysis (FTA)
Fishbone (Ishikawa) Analysis
8D Problem Solving
DMAIC (Define, Measure, Analyze, Improve, Control)
…

Among these, Root Cause Analysis is one of the best-known and most intuitive approaches, particularly for technical and project-related problems.

Simplicity Is Key:

Considering the typical conditions on construction and engineering projects — limited time and resources, competing priorities and pressure to solve problems quickly — there is a strong case for applying a simple and pragmatic structured approach.

It is not always necessary to follow a recognised methodology in every detail. The objective is not to demonstrate perfect application of a particular method, but to introduce sufficient structure and discipline to solve the problem effectively.

Depending on the complexity and significance of the problem, selected elements from established methods can be combined and adapted as appropriate.

Specialised software is also not necessarily required, particularly if the team is not already familiar with it.

Although the basic principle of Root Cause Analysis is relatively simple and intuitive, it is sometimes presented in an overly academic or complicated manner. Extensive terminology, numerous tools and formal procedures can make the method appear unnecessarily difficult, particularly to project team members who are not specialists in structured problem solving. This may discourage project teams from applying it in practice.

Figure 2 – A Pragmatic and Simple Approach to Root Cause Analysis

A practical approach could include the following:

Select suitable members of the problem-solving team
- Establish a multidisciplinary team where appropriate.
- Include people with the necessary technical knowledge and practical experience.
- Select people who are recognised and respected within the project team.
- Involve people who are motivated, creative and willing to contribute constructively.

Appoint a Facilitator / Problem-Solving Coordinator
- For more significant problems, one person should coordinate and facilitate the problem-solving process.
- The facilitator does not necessarily need to be the technical expert or the person expected to provide the solution.
- The main role is to keep the process structured and focused, encourage contributions from all team members, challenge assumptions and ensure that conclusions are supported by the analysis.
- Depending on the problem and project organisation, this role may be performed by the Project Manager, a discipline lead or another suitably experienced team member.

Apply the essential problem-solving steps
- Select the right problem to be addressed.
- Clearly describe and define the actual problem.
- For event-related problems, such as equipment trips or failures, establish a timeline showing the sequence of events.
- Analyse possible causes using Fault Tree Analysis and/or the 5 Whys, as appropriate.
  Figure 3 – Simplified Fault Tree Diagram – Warehouse Fire Example
- Identify the root cause(s) and relevant contributing factor(s).
- Develop possible solutions and consider their main advantages and disadvantages.
- Recommend the preferred solution or course of action.

Documentation (Brief Report)
- Prepare a brief and focused report documenting the problem, the analysis performed, the identified root cause(s) and contributing factors, the solutions considered and the resulting recommendation.
- The report should not be unnecessarily long or detailed. Its purpose is to document that the problem was systematically analysed and to support the decision-making process.
- It also provides a useful record for future reference, particularly if similar problems occur again.

The methodology should therefore be proportionate to the importance and complexity of the problem. A relatively simple problem may require only a few of these steps, while a major technical or commercial problem may justify a more comprehensive analysis.

The method should support solving the problem — solving the problem should not become secondary to applying the method.

7. Practical Conclusions

In practice, many projects either do not use a structured problem-solving method at all, or apply methods that are too complex or sophisticated for the problem at hand, with the associated consequences described above.

The objective should therefore be to apply a structured but pragmatic approach, proportionate to the importance and complexity of the problem. The following principles may provide useful guidance:

Select the right problem. Not every problem requires the same level of attention or analysis.
Define the actual problem before trying to solve it. Avoid confusing symptoms with the problem itself.
Keep the methodology simple and proportionate. The complexity of the approach should reflect the importance and complexity of the problem.
Use the right people. A motivated multidisciplinary team is often more important than a sophisticated methodology or specialised software.
Distinguish root causes from contributing factors. Addressing contributing factors alone may not prevent recurrence.
Focus on solutions and decisions. The purpose of the analysis is not to apply a methodology perfectly, but to support effective decision-making and implementation.
Document the essential results. A brief report should demonstrate how the problem was analysed and provide a record of the conclusions and recommendations.