Describing incidents

Please see Kathy Reid's blog entry, "The benefits of describing ITIL incidents in object-deviation format."

Many tools and methods can support incident management and problem management. The "Ishikawa Fishbone Diagram" comes up often in problem management, as a way to graph and define root causes. Kathy Reid's post discusses the "Kepner Tregoe" method (which I'm not familiar with myself).

Essentially, the technique she mentions is to describe an incident as what is different than the expected results. This reminds me of one definition of quality, as "conformance to requirements." When there's a deviation, that means there is a reduction in quality. Defining the incident principally by the deviation seems like a quick way to isolate the issue as well as to provide data for problem management later.

Individual site contributors are solely responsible for the content of this web site.