Welcome (course overview) - ITIL Tutorial

- [Voiceover] Problem management skills make a big difference in individual and team effectiveness. Often such skills are just assumed, but just as often, people have had no formal training in them. That's why I made this course, to cover seven key techniques and close that gap for you. I'm Dave Pultorak, and I've been putting these techniques to work for over 15 years. I'm excited to share this vital information with you, so let's get started. Let's start by making sure we're clear on what we mean by a problem. You can see hear from this definition, that it's not the same as an incident. An incident is the symptom of a problem. So for example, if there are 800 people who've called the help desk this morning because their drive mappings have disappeared, each of these calls is an incident. The unknown, underlying cause of all these incidents is a problem. IT services experience problems like outages or poor response time due to issues in or between components that make up a service. ITIL identifies the broad categories of service components as people, processes, products and partners. This set of categories is important to understand, because as you seek to prevent and solve problems, you'll need to at least consider each of these as possible sources for causes and solutions. What should becoming clear to you from these definitions is that we're talking about problem management, not just problem solving. That is, we're concerned with techniques that prevent problems in the first place, including applying learning from actual problem handling situations to doing better next time, as well as preparing to react better, and get to the root cause and resolution quicker when problems do occur. ITIL talks about the effective and efficient use of the Four Ps. People, processes, products, that is, technology, and partners, that is, suppliers. You can think of the Ps as four categories where causes of problems and action items and solutions can be found. I've incorporated the Four Ps as categories in the seven techniques we'll cover for consistency across the techniques, and to align better to putting ITIL in to practice. Our goal in applying these techniques is the right amount of timely analysis and insight, not perfection, and certainly not insight without action. Effectiveness of decisions and actions are time bound, like a mariner's decision to change course. The art in this is keeping your eye on the goal. Doing just enough timely analysis to spur effective action. Note that I've rationalized the techniques presented here to include action steps. Problem management is about driving towards a better reality by isolating and taking action to eliminate the causes of problems. But that's not enough, we need better perception too, and that requires communicating with key stakeholders to demonstrate that we have a firm grasp on what the problem is or was, what we've done or are doing, or will do about it, and how we have or will isolate it, and who is doing what and by when, in terms of action items. When you stand back and look at the set of techniques, you may find unnecessary variations. For example, in the use of categorization and prioritization schemes, or in steps for action and communication. These variations get in the way of both uptake and use of the techniques, when used as a set. I've rationalized these differences across the seven techniques presented. And I've also aligned them to use ITIL's Four Ps as categories, more on that later. We've used the same example of a share point collaboration service as the basis for exercising all techniques in this course to provide consistency and because we can leverage the ready made scenarios shown here. Use of a single example with a detailed reference should help you better see the scope and applicability of each technique and how they fit together as a set for problem management. I wrote this course to introduce you to the what, why and how of problem management techniques that ITIL mentions to enable you to understand all seven techniques at a high level and to begin to apply them. There are many more variations and details of these techniques that it makes since for us to cover here. That's why we've provided where to go at the end of this course, as a set of links for more information on and resources for these techniques. ITIL mentions a number of problem management techniques from a variety of sources, but it does not tell you how to do them. This course exists to provide those details to help you understand the what, why and how of each technique to improve your ability to prevent problems in the first place, and to respond more effectively when they do occur. The first technique we'll cover is brainstorming. Brainstorming is a method of shared problem solving in which all members of a group spontaneously contribute ideas in round robin fashion, that is, in which each person contributes ideas, in turn, until the team runs out of ideas or energy to continue. Cause-effect analysis is used to chart cause and effect relationships. The diagrams that result are also known as Ishikawa Diagrams, after their creator, Kaoru Ishikawa, or tree diagrams, or fish bone diagrams, because the shape the charts take as they're mapped looks like a fish bone or tree branches and spurs. Kepner-Tregoe Problem Analysis, was developed by Charles Kepner and Benjamin Tregoe as a structured approach to finding the route cause of a problem in four phases, describing the problem, identifying possible causes, evaluating possible causes and confirming the true cause. The power in the Kepner-Tegoe method is it's simplicity and rigor. It helps us make sure we as a group, really nail down the cause before jumping to solutions. Fault tree analysis is a technique for identifying the chain of events that has caused or may cause a problem. For example, a service outage or a performance degradation. Fault tree analysis links basic, resultant, conditional and trigger events using Boolean logic operators, and, or, xor and the like, to graphically illustrate chains of events and the logic behind them. Component failure impact analysis is a technique for mapping components of a service and identifying which are single points of failure and which have fail over capabilities and to what degree. Service outage analysis is a technique where you examine past outages to identify the most significant and addressable contributors to the occurrence and duration of outages. That includes people, processes, products and partners. We do this with an eye towards taking steps to reduce the risk of, and time taken to recover, from potential future outages. Problem review is a technique for examining how a problem situation was handled after the fact, with an eye towards doing more of what worked well and less of what didn't, in similar future problem situations. In the context of ITIL, the scope of problem review includes examining how to improve in four dimensions, known as the Four Ps of ITIL, namely people, processes, products, that is technology, you know, like IT, and partners, that is, suppliers or vendors.