Structured problem solving: the 10 point plan

In a previous article, I wrote about systems thinking as an essential tool when looking at and designing organizations.

I have a similarly important tool here: structured problem-solving, which looks so simple that it is often underestimated.

It has a role like kata in karate, or the practice of etudes by pianists. Professional skiers also go to the glacier in summer to perfect their technique.

Problem solving and improvement

Problems and improvements are often mostly sides of the coin. Their common core is a target-actual deviation. We describe the problem solving process

Structured problem solving in a lean management system can be characterized this way:

  • Everything described or claimed should be based on verifiable facts, not assumptions and interpretations.?
  • Problem solving is never complete, it does not begin and end with the implementation of an improvement plan.
  • The implementation process is a learning opportunity to figure out how to make progress toward the target state.?

The process is designed to counteract a common thinking trap, when people make the common mistake of mechanically resorting to a known or preferred problem-solving method or, worse, quickly finding a solution.?It systematically helps to first identify backgrounds and principles before deciding on a course of action.

The process is used for a wide variety of non-trivial problems and in different contexts , such as.

  • Troubleshooting, e.g. in quality assurance
  • Deviations from a standard, e.g. For process improvements
  • Goals in a continuous improvement process
  • Innovation or exploring new opportunities

It is therefore also described in different variants. We try to be as generic as possible here.

Improvements are embedded in a continuous improvement process as prototypically described in the PDCA cycle.

The 10 point plan for structured problem solving

  1. Name the problem. The starting point is a problem or a desired improvement for which you do not yet know the solution or the solution path.
  2. Assemble team. Problems complex enough to warrant this process are almost always better solved by a team that brings together different completences and approaches.
  3. Analyze situation. They identify and describe in as much detail as possible the current state and which aspects should be improved.
  4. Clarify goals. What is to be achieved? Why is this important? How do you recognize a good solution? Make it detailed enough so that you can decide if the goals were met in the end.
  5. Find ideas for solutions. Then you need solution candidates. This may require research into existing solutions or a creative process. You may want to use one of the many creative techniques. As a rule, these are not yet fully developed drafts.
  6. Review and evaluate ideas. The candidate solutions are tested. They evaluate how the ideas help achieve the goals set. Some ideas will be selected, looked at more closely, and further detailed as appropriate.
  7. Make decision. Depending on the nature of the problem and the scope and impact of the solution, it must be clarified beforehand who can make this decision.
  8. Implement solution. The selected solution (or bundle of measures), is elaborated and implemented.
  9. Check success. Does the solution meet the original objectives from step 4? Does it deliver the desired result? If necessary, improvements are made or the problem-solving cycle starts over again with a new task.
  10. Communicate result. The result – both success and failure. is valuable information for other groups and teams. Typical agents in organizations are middle management and communities of practice.

Each such problem resolution is part of a feedback cycle for continuous process improvement. Feedback and experiments are an integral part of this – they are the central concepts of empirical processes. At the beginning of a project, rarely (never?) all necessary information is completely available to deterministically plan all steps and intermediate goals in advance. This means risk, uncertainty and blurring and is uncomfortable. However, we also learn that more information will appear as time goes on.

This has profound consequences in agile teams and also for relationships with other teams – and on the company’s setup.

Embedded in the PDCA cycle

The PDCA cycle of Plan – Do – Check – Act is the backbone of continuous process improvement.

W. E. Deming was interested in how innovations get from teams into the organization and propagated constant and continuous process improvement.

Deming’s PDCA cycle, expanded to four elements, summarizes this continuity:

Plan: A process improvement is planned, improvement potentials are identified, the current state is determined and the target state is developed, a measure is identified.

Do: The improvement is tested as an experiment and optimized practically.

Check: The tested new process is carefully checked and released.

Act: The released new process is introduced and rolled out operationally.

PDCA and the learning organization

It is the fourth step Act that makes the difference: it ensures that the important innovations are spread throughout the company, that these individual improvements can become a coherent continuous improvement process. It is thus a core element of the learning organization.

In agile methods, this continuous improvement process is applied both within the team and for the sharing and diffusion of new ideas between teams and organizational units. In Deming’s original, middle management is mainly responsible for this transfer.