ITIL: Dangers of Treating “Everything” as an Incident

September 1, 2011 | Author: PM Hut | Filed under: ITIL

ITIL: Dangers of Treating “Everything” as an Incident
By Bob Faerman

Whether or not formalized processes are in place, most IT groups do recognize that there are distinct differences between activities that ITIL would formally classify as incidents, fulfillments, problems, and the projects that are undertaken to improve an architecture or add new functionality. The user community, including senior management, also realizes that the restoring service (incidents) is different than a request for something new (fulfillments), though some grey area may exist between problem management and projects. So why do IT groups attempt to track them all in the same queue, as incidents?

Perhaps the reason is as much financial as anything else, mixed with a misunderstanding of some of the risks of mixing different activities into dissimilar groupings. Most popular software tools license an individual module for each ITIL process, thus to implement service management properly for incident management, request fulfillment and problem management would require the purchase of at least three modules with integration between them. A short-term, misguided solution is to implement an incident management tool and have everything classified as an incident. Though this may work initially, there are deficiencies in the approach that will quickly be realized.

There are many differences between incidents and fulfillments. The most important difference is that an incident is defined as a disruption of service, whereas a fulfillment is a request for something new which may require an approval or purchase, or in practical terms, much more time to complete. Problems and projects obviously take extended periods of time. Metrics thus become difficult to calculate, or at the very least skewed.

Another key difference is that every incident must be closed with a successful restoration of service. Problems and projects usually require the business’s approval and a budget to close, and could remain open indefinitely if they have a low priority or are not funded. Fulfillments may share a requirement for an approval (financial or other authority, such as security or need to know) or budget, and may be denied or delayed. One of the responsibilities of the service desk may be to explain why a user cannot have their request granted, or in some cases, separate a multipart request into what is and what is not approved.

This leads to the concern of measurement of units of work or output. An incident in its pure form is one unit of work; one end user calls with service disrupted and one service desk employee helps them restore service. Fulfillments do not necessarily equate to one unit or work. Is a request to create fifty user accounts one unit of work or fifty units of work? Is a request to purchase and install a software image on fifty computers one unit of work, fifty units, or one-hundred units? The definition of one unit of work, most likely unimportant to the request fulfillment process, becomes very important if fulfillments are treated as incidents, and is often overlooked in the initial decision to combine both into one queue.

There are numerous other inherent problems in treating everything as an “incident”. The effort to avoid software licensing costs can easily undermine the success of an ITIL implementation because of the underlying differences between the different processes. If an organization does not have a budget to license all of the modules that they need, they should find an alterative method to track individual processes, which could include spreadsheet or standard office database products. Once the processes are combined into one, which is typically an incident management module, service level agreements (SLAs) become difficult to meet and measure, and management of customer expectations in each of the individual process becomes challenging at best.

Bob Faerman, PMP, ITIL V3 Expert, PSM, CISSP is an information technology program / project management / service management veteran with more than twenty years experience in managing the design, planning, development, installation, integration, maintenance, support, documentation and training integral to successful information systems. Bob has excelled in leadership, program management, project management, sales, marketing and education roles; where he has been consistently recognized for exceeding customer expectations and revenue targets.

CertSpeak is a consortium of talented information technology subject matter experts, authors and speakers specializing in project management, service management and information security disciplines. Every member of our team has an extensive, proven professional track record and holds multiple industry recognized certifications, including Project Management Professional (PMP), ITIL Expert, Professional in Service Management (PSM) and Certified Information Systems Security Professional (CISSP).

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories