This month’s question
What are the differences between problem solving and root cause analysis (RCA)? What are some tips for effectively and efficiently facilitating problem solving, RCA or both?
In practice, problem solving and RCA are interchangeable. Technically, problem solving involves assessing a process from end to end—from the event occurrence to the sustained prevention of recurrence. A typical problem-solving approach is the eight disciplines method.
RCA, on the other hand, involves investigating the incident, and identifying and confirming the root causes. Some organizations also differentiate between RCA and root cause corrective action, which involves identifying and confirming the root cause, and implementing corrective actions.
Here are some of the most important aspects of facilitating problem solving and improvement projects:
Before problem solving, the problem-solving team must select a trained facilitator. Some organizations expect the problem owner to also function as the facilitator, but that could be problematic. Problem owners typically are under pressure to resolve an issue as quickly as possible, which means they may pressure the problem-solving team to reach a temporary conclusion quickly rather than achieving a permanent, sustainable solution.
A facilitator, on the other hand, has a neutral role and can ensure the RCA process is followed. The facilitator should complete the following tasks before the problem-solving team meeting:
- Work with the problem owner to ensure the problem-solving team has collected adequate background information and pertinent data affecting business metrics.
- Work with the problem owner to present background information and the business impact to management for sponsorship. Typically, problem-solving efforts fail without management’s commitment. Having management’s support also will make it easier for the problem-solving team to get the resources and support it needs to follow through with corrective actions.
- Train team members in the structured problem-solving process and basic quality tools. Team members must understand various terms such as symptom, root cause, containment, correction and corrective action. It also is important for team members to understand the stages of team dynamics.
- Accommodate virtual team members who will be joining the meeting via video or web conferencing. Assure them that they are as important as onsite participants.
- Work with the problem owner to ensure the problem-solving team is cross-functional and includes supplier and customer representation when appropriate (this may require management support). A diverse problem-solving team offers unique perspectives.
- Be cognizant of the organizational environment (layoff announcements, mergers and acquisitions, product recalls, legal proceedings)—team members’ minds may be elsewhere. Get the sponsor—a management-level individual relevant to the problem area—to attend the meeting to answer questions and alleviate any concerns.
During the problem-solving process, the facilitator should:
- Revisit the project scope in every meeting and ensure it doesn’t expand.
- Understand the competing priorities for resources in the organization and be flexible. For example, ensure the timing and duration of meetings allow participants to perform their daily tasks.
- Set realistic ground rules for meetings (as an input from the team itself) and enforce them. Implement a laptop-down policy, for example, so participants stay focused on discussions and participation. Provide 10-minute breaks every hour so participants can catch up on emails, make calls and ensure business continuity.
- Solicit input from quiet participants by redirecting the conversation and keeping everyone engaged. If a participant is dominating the conversation, acknowledge his or her contributions and tactfully request that he or she allow others to contribute. Use tools such as silent brainstorming on sticky notes first to get inputs from reluctant participants.
- Observe participants’ body language and anticipate frustration, anger, tiredness and dismissiveness. While time management is important, team dynamics are more important for continuity of problem solving, so take breaks to defuse the situation.
- Don’t get hung up on a tool’s theoretical approach—adapt it to the problem at hand. Engage participants by making it relevant. Modify five whys analysis from a single causal chain to a multi-branching fault tree analysis, for example. Or, modify cause and effect diagram labels when analyzing a software problem.
- Keep the use of tools to a minimum and make them simple and easy. Problem solving is about getting results, not a participant showing off his or her ability to use complex tools and analyses.
- Stay neutral and resist aligning with the authority or influence in the room. Respectfully challenge assumptions and hypotheses. Ask for data. Make everyone—not just a few members—feel important.
- Schedule regular meetings with the problem owner outside of the problem-solving activity to discuss adherence to scope, progress, escalation to sponsors, questions, concerns about participants’ behavior or performance, or the need for additional training, for example. Reach out to virtual team members for their feedback and allow all participants to communicate directly in case of questions or concerns.
After the problem-solving project, the facilitator should work with the problem owner and the sponsor to acknowledge the team’s accomplishments and communicate successes and lessons learned with other problem-solving teams. Develop and nurture the new batch of problem solvers—don’t let this become a forgotten skill. And don’t forget to thank management for its support throughout the process.
ASQ, “Problem Solving,” asq.org/learn-about-quality/problem-solving/overview/overview.html.
ASQ, “What Is Root Cause Analysis (RCA)?” ASQ, asq.org/learn-about-quality/root-cause-analysis/overview/overview.html.
Ramu, Govind, “Expert Answers: July 2018,” Quality Progress, July 2018, pp. 8-9.
Wikipedia, “Tuckman’s Stages of Group Development,” https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development.
This response was written by Govind Ramu, Program Manager, E2E Closed Loop Learning, Google, Mountain View, CA.