Every business faces this challenge of differentiating Incident management from Problem management as these two ITIL processes are closely aligned with each other. ITIL Problem management is one step ahead of Incident management which performs Root Cause Analysis (RCA) to identify, track and resolve recurring incidents permanently. Problem management prevents incidents from occurring and ultimately aims for no incidents. Problem management can be proactive as well as reactive. Businesses recommend proactive Problem management to prevent incidents and ITIL Problem management process follows specific steps such as:
- Problem detection
- Problem logging
- Investigation & diagnosis
- Resolution – workaround or permanent
In order to perform this Problem management effectively, there are different techniques available. Let us discuss four popular techniques that are easier to implement.
Bring all key stakeholders involved in a problem in one place and discuss possible causes. This method is ideal for highly creative teams and eliminates any silo situation.
- Involves round robin discussion among participants
- A high volume of ideas in a shorter time
- Faster and enables diverse idea generation
- Encourages full participation as every person contributes to problem analysis
- Discuss and decide the brainstorming question
- Let every person share his/her idea
- Review the list of ideas to clarify and remove any duplicates
- Prepare an action plan to communicate to stakeholders
Ishikawa / Fishbone / Cause and Effect Analysis
The cause-effect analysis describes relationships between a problem and its possible causes. For example network downtime is a problem which might have possible reasons such as router malfunction, network error, disaster, etc. Therefore, this method analyses various causes and defines relationships. This method is also known as Ishikawa or fishbone diagram that analyses primary and secondary causes of a problem. Causes, in turn, have different categories such as people, product, process, and partners. This method is used for reactive problem management. Therefore, it is essential to define the problem statement precisely.
- Get a thorough picture of all possible causes for an effect/situation
- Ideal for complex problems
- Has many possible causes and contributing factors
- Post the analysis, discuss action items to improve the process
Problem – Network outage
Stakeholder – Employees
Impact – Productivity loss for an hour
Evidence – No internet connection
- Define problem statement
- Add cause categories as fish bones
- Use traditional brainstorming techniques to fill in possible reasons for the “ribs.”
- Classify and prioritize primary and secondary causes as trunks
Kepner Tregoe Problem Analysis
A logical approach to problem-solving, starting with defining and then describing the problem. Possible causes are established, and then tested, and finally, the exact cause is verified.
Systematic four phase Root Cause Analysis (RCA) for complex problem analysis. Kepner Tregoe (KT) is applicable for both proactive and reactive problem management. It involves problem analysis as well as potential problem analysis.
- What’s going on – Situation Appraisal
- Why did this occur – Problem analysis
- Actual cause for the problem and alternatives – Decision analysis
- What is the plan of action and risk associated – Potential problem analysis
Kepner Tregoe focuses on finding the root cause before getting into solutions. It is a group problem-solving technique to identify actual root cause with the help of evidence. KT enables group problem solving, speed and precision. KT framework includes “is” and “is not” kind of analysis.
Problem : Application Poor Performance
Watch the video here to know more.
Five why strategy is a simple and effective mechanism to understand the root cause of a problem by asking subsequent “why” questions. It is one of the six sigma techniques to identify the actual root cause of a problem and take appropriate countermeasures to prevent from occurring in future. It defines the relationships between different root causes. However, it is significant to frame the questions properly to find out the actual root cause. Asking why question five times is just a rule of thumb, and it varies depending on the problem complexity.
- Gather a group of people who are familiar with the problem
- Ask “why” questions – ‘n’ times depending on the complexity and type of answers
- Define action items to address the issue and prevent it in future
Although asking “Why” repeatedly sounds like the behavior of a child, it is highly effective if you can answer the why’s correctly.
The above listed techniques help you to understand the impact and complexity of the problem. Your organization could already be using one of the techniques, or none. If not, try implementing one of them and see the change in the speed and ease of problem resolution. If you liked this, you will love our Ultimate Guide to ITSM Best Practices