Put your ITIL® 4 Practices on Steroids

How do you get all your IT staff to be on the same page quickly and effectively in terms of conforming and enhancing the ITIL 4 PRACTICES?

The Problem-solving for ITIL® methodologies can help with this. This methodology is the “how-to” for many of the ITIL practices, dimensions, and guiding principles. We can help with the way you approach the practices of Incident Management, Problem Management, and Change Control. We help the IT professional to determine “WHAT happened”, “HOW it happened” and “WHY it happened” with templates and tools specifically customized to IT incident/problem situations. We arrive at quick, accurate and permanent results through our own principles of:

• Ask the right question from the right person to get to the correct answer! This principle ensures we have the right core people on the bridge and have the other potential information sources on call. This ensures we are not “abusing” Subject Matter Experts (SMEs).
• Use RELEVANT data and actively reject irrelevant data. All the KandF tools and techniques have worked questions applicable to IT-specific incidents and this ensures a framework of questions you can ask and when completed you are assured of having enough data to solve the incident.
• “The devil lies in the detail” is another principle we instill in IT professionals to help them to identify the most important detail quickly and effectively. We make sure they are dealing with the correct and most specific OBJECT and FAULT.

By recognizing the correct FAULT, we ensure we identify the correct information sources to collaborate with, which supports the first principle above. Once we have the correct information sources to work with we use the appropriate template with very specifically worded questions. This ensures we get a quick factual snapshot of the problem to be solved or the solution to be found. This approach would provide the “how-to” to collaborate with information sources most effectively and successfully.

Now that you know how we do it we want to get back to the three practices of IM, PM, and CC. Let’s look at each one of them separately:

• Restore Service – At this point, we only want to determine “WHAT happened” for us to take the appropriate restoration action to restore service. We do this by correctly and accurately identifying the factual snapshot surrounding OBJECT, FAULT and IMPACT as mentioned above. Imagine we are having a current incident whereby corporate staff does not receive any incoming emails. The object would be “incoming mail”, the Fault is “not received” and the unique IMPACT factor is that it only happens to incoming mail and not outgoing mail. Based on these facts the team determined that the “Mail Exchange” server must be at fault. They quickly found a way to circumvent this server and restored service.
• Technical Cause – We have now restored the service, but we do not know “HOW it happened”. For this, we need to use the rest of the template and complete an exercise on “factor analysis” using factual “IS” data and what it could have been, “BUT is NOT”. This would bring us to the mutual understanding that in some way the “Mail Exchange” has reached full capacity without us receiving an alert or knowing that it was full. So, now we can fix this situation by increasing disc size and that would remove the technical cause.
• Root Cause – However, if we do not find “WHY it happened” this situation is ripe to recur at some time in the future. At this stage, we use the 5 WHYS in conjunction with our factor analysis and come to an understanding of why we did not receive an alert. In this case, the alert was generated but went to a wrong email address and was not acted upon.

Imagine having one template with worked questions and key actions that would ensure a seamless handover between Incident Management to Problem Management to Change Control without having to reinvent the wheel. All an expert needs to do would be to build on what is already there and arrive at consensus actions quickly, accurately and effectively.