Loading presentation...

Present Remotely

Send the link below via email or IM


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.


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

Inadequate troubleshooting capability in IT organizations

Why is it common that incident resolution creates new incidents? Why do some incidents and problems persist week after week? And, what should we do about it? Get the answers in this presentation.

Thomas Fejfer

on 12 June 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Inadequate troubleshooting capability in IT organizations

Let us look at how we troubleshoot
While IT becomes more and more business critical
IT also becomes more and more complex,
and so do the problems we face.
causing inefficiency and loss of business.
However, the troubleshooting capability cannot keep up
When we face a problem, we match the problem with the patterns stored in our brain to find a response.

This is called pattern recognition or intuition, and it is based on knowledge, experience, assumptions, and gut feeling.
Systematic troubleshooting
We cannot solve all incidents and problems with our knowledge and experience!

We need systematic troubleshooting to assist us when the situation is unusual, it previously went wrong, or the stakes are high, instead of the commonly used, inefficient, and dangerous 'Trial and Error'.
What should we do

That is why technical specialists can solve more problems within their technical domain than for example a service desk supporter.

They simply have more patterns stored.
The more knowledge and experience, the more patterns are stored, and the more responses are available.
The result of this pattern recognition has different outcomes:
Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn’t mttaer in what order the ltteers in a word are, the olny iprmoetnt thing is that the frist and lsat ltteer be at the rghit pclae. The rset can be a total mses and you can still raed it wouthit porbelm. This is bcuseae the human mind deos not raed ervey lteter by istlef, but the word as a wlohe.
We face a problem, we recognize the pattern, we apply a change, and the incident or problem is solved.
Pattern recognition is an amazing capability which enables us to solve many incidents and problems quickly.

Jumping to conclusions based on our pattern recognition is efficient if:
the conclusions are likely to be correct, and
the costs of an occasional mistake acceptable, and
the jump saves much time and effort.
(example of pattern recognition)
We face a problem, we confuse the pattern, we apply a wrong solution, and the incident or problem persists.
Sometimes our pattern recognition deceives us because similar symptoms can have different causes.

In best case, we have just wasted labor and business performance.

In worst case, we have also introduced new incidents caused by the change we made to solve the original issue.
(example of pattern confusion - is it a rabbit or a duck?)
We face a problem, we do not recognize the pattern,
Γ(z)=∫_0^∞▒〖t^(z-1) e^(-t) dt〗 tan e^(-γz)/z ∏_(k=1)^∞▒〖(1+z/kdt)^(-1) e^(z\/k) 〗
we are stuck, and the incident or problem persists.
When we lack a pattern that fits the scenario, we often turn to 'Trial and Error'.

But it is risky when the situation is unfamiliar, it previously went wrong, or the stakes are high, because 'Trial and Error' often leads to new incidents, and without luck the original incident or problem will persist.
Wrong pattern
Right pattern
No pattern
Don't base your troubleshooting solely on luck unless of course you have plenty of resources and don't care about quality
Efficient and effective troubleshooting requires a well stocked toolbox filled with useful methods and techniques, and of course knowledge and experience which you get by solving incidents and problems.

One tool (method or technique) is not sufficient.
in IT organizations
by Thomas Fejfer, BlueHat P/S
Some very useful tools
Continue here if you want to see how Kepner-Tregoe can improve your ITIL processes:
Kepner-Tregoe® is a Registered Trademark of Kepner-Tregoe, Inc. in the United States and other countries.
ITIL® is a Registered Trade Mark of the AXELOS Limited.
5 Whys (for simple problems)
Cause-Effect Diagram
Kepner-Tregoe Clear Thinking
Rapid Problem Resolution (RPR )
Apollo Root Cause Analysis
Why is it common that incident resolution creates new incidents

And, what should we do about it

Why do some incidents and problems persist week after week

Full transcript