Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Problem Investigation and Diagnosis

Seven practical steps
by

Thomas Fejfer

on 12 June 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Problem Investigation and Diagnosis

Step 1: Review the problem description
Check that the problem description is specific enough for problem solving.
Go and see the symptom with your own eyes to understand the problem.
Define the undesired outcome in terms of the negative business impact to get a unique starting point.
Step 3: Create a timeline
A timeline documents events in chronological order to show which events may have been triggered by others – or to discount any claims that are not supported by the sequence of events.
A timeline describes events that relate to people (who), places (where), and things (what) in a linear time frame (when).
A timeline is a useful tool in the initial phase of the investigation, but the sequence of events does not explain the cause-and-effect relationships.
Step 5: Draw a cause and effect diagram
Draw a simple cause and effect diagram to understand why the incident occurred.
Keep asking 'why' until the answer is out of your control or a desired cause.
Make use of e.g. Kepner-Tregoe® Problem Analysis and/or Rapid Problem Resolution (RPR®) if you cannot answer the 'why' and you need the answer to solve the problem.
Step 4: Make a sketch
Make a sketch that shows the main components involved and how they interact. The sketch is important for the common understanding of the problem and for later reference, discussions, identification of possible solutions etc.
SMEs will typically be able to make the sketch based on the symptom and their knowledge and experience, but also by using the information from the timeline.
Step 7: Choose the best solution
Make use of e.g. Kepner-Tregoe Decision Analysis if the choice is not obvious.
If the solution is obvious, the decision makers are familiar with Decision Analysis, and there is not a lot of resources and costs involved, it is possible to use a fast version of Decision Analysis as shown in the example.
Step 2: Form a Problem Solving Team
You need a problem coordinator who is capable of facilitating a systematic problem investigation including the use of different problem solving techniques.
It is preferable if the problem coordinator does not have a deep knowledge of the nature of the problem to stay objective during the problem solving.
Then you need some subject matter experts (SMEs). It is preferable if the SMEs are also trained in systematic problem solving, but it is not mandatory.
Step 6: Identify possible solutions
For each cause ask: “What can we do to remove the cause?” or “What can we do to prevent the cause from having a negative effect?”
Think out of the box and challenge the traditional thinking – often coming from the IT experts.
List possible solution without discussion
For more details see the white paper:


No registration needed!
simple
http://sim4people.com/library/
Kepner-Tregoe is a Registered Trademark of Kepner-Tregoe, Inc. in the United States and other countries.
RPR is a registered trademark of Advance Seven Limited.
The objective of reactive problem management is to eliminate recurring incidents or minimize the impact of incidents that cannot be prevented. To do this, it is necessary to understand why the incident(s) occurred, and the key activity in problem management to understand this is ‘Problem investigation and diagnosis’.

The goals of problem investigation and diagnosis are to find the root cause(s) and to identify a solution that prevents recurrence or minimize the adverse impact by answering the questions “Why did it happen?” and “What should we do about it?”. However, ITIL® does not provide much guidance on how to perform problem investigation and diagnosis.
ITIL® is a registered trade mark of AXELOS Limited.
The purpose of this presentation is to show how a combination of the best of the most recognized methodologies and techniques can be used for problem investigation and diagnosis for primarily complex and unusual IT problems.

Complex or unusual problems are problems where the failing technology is unidentified because the pattern (symptom) is not recognizable, or you have seen a similar pattern but suspect a different cause.
Purpose
Introduction
Problem investigation and diagnosis is about picking the right tools from your toolbox for the specific problem and answer the questions: “Why did it happen?” and “What should we do about it?” There is not a universal tool that can do it all. The tools described in this presentation can help you, especially when you investigate and diagnose complex or unusual problems.

For simple problems, there are techniques like 5-whys and Fishbone diagram, but be aware of their limitations. Both techniques are not repeatable meaning that different people often identify different causes for the same problem, and the problem solvers will only find causes for things they already know about. Furthermore, 5-whys is a linear questioning technique that can easily lead you into a blind alley, and Fishbone diagram is a categorizing brainstorm, that it is not showing cause and effect relationships. However, for basic problems both 5-whys and Fishbone diagram can be sufficient.

If you do not know for sure why a problem occurred and you start implementing changes in the hope of finding a solution, then you are actually using Trial and Error. Trial and Error can be acceptable if the solution is likely to be correct, and the consequences of an occasional mistake acceptable, and it saves much time and effort. But for complex and unusual problems Trial and Error is probable the worst “problem solving technique” because success is up to chance and it often leads to new incidents.
Conclusions
Full transcript