Problem management is one of the 17 service management practices of ITIL 4 and is one practice you need to know in depth for the exam. You need to be able to recall its definition, purpose, terms associated with it and how it works. The purpose of problem management is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors.
In this definition, there's two key terms that you need to be able to recall for the exam. They're the words problem and a known error. A problem is a cause or potential cause of one or more incidents. If you can pause right here and search for one of the articles here on itil.diontraining.com regarding Incident Management, it would help to know that an incident is an unplanned interruption to a service or a reduction in the quality of that service. If this happens more than once to the same type of thing, then it becomes a problem. Sometimes though a problem can be classified as a known error.
A known error is a problem that has been analyzed and has not been resolved yet. For example, you recently underwent a website migration from one server to another. During that migration, the log-in link was routing users to the wrong place. Now while your web developers were working to resolve the underlying issue, you were able to notify your users of this issue and told them that you had a known error and gave them another link to access the log-in page. By doing so, you created what's known as a workaround. A workaround is a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Sometimes these workarounds will help you to reduce the likelihood of incidents from occurring again, and these workarounds are documented in your problem records. Workarounds can then be created at any stage, and they don't need to wait for you to fully analyze the problem and have the full complete solution done. Instead, if you have a workaround that's been documented early in the problem control stage, this can be reviewed and improved after the problem analysis is fully completed.
At its core, there are three major steps inside problem management. The first step is problem identification, the second is problem control, and the third is error control. In problem identification are things like trend analysis, identifying what recurring incidents or major incidents have happened, supplier and partner information, software developers, testers, and projects that are on-going and identifying any possible issues that may turn into problems. In problem control, you're trying to prioritize and manage based on the risk. You might have 5, 6, or 7 problems, but only have enough time and money to solve one of them right now. Which one to do first becomes a prioritization and risk management decision. Do your problem analysis from the perspective of all four dimensions. Think about it through all four of those lenses, because it might be a problem that can be solved with people as opposed to technology or vice versa. And then we go into error control. With error control you're trying to identify potential permanent solutions for this problem. This allows you to reassess any status of known errors and improve workarounds.
Problem management is a practice that relies heavily on other practices as well. It has a large amount of overlap with the incident management, risk management, change control, knowledge management, and continual improvement practices. Each of these practices will either provide an input to problem management or receive information from problem management to better do their own jobs.
Problem management impacts a lot of the value chain activities. In improve, problem management and doing it effectively is going to provide a better understanding of what needs to be done to reduce the number of incidents which leads to improving your products and services. Engage on the other hand, is going to be where you take problems that have significant impact to your services and tell your users and customers about it.
From a design and transition perspective, problem management is going to provide information to help improve testing and knowledge transfer from those who are designing and transitioning those services into the real world. Once they hit the real world to deliver and support, that's when your service analysts have to know about it. From an obtain and build perspective, it's very similar as well. Problem management activities are going to help identify product defects that are managed as part of the overall value chain activity. And that information is transferred to the transition team and then to the deliver and support team. In deliver and support, problem management is going to make a significant contribution just like incident management because as you identify repetition of incidents, you can then try to find timely incident resolution and solve them for the longer term by solving the underlying problem.