Skip to main content

ITIL in the enterprise (the cart before the horse)

What problems are YOU addressing? This is a very simple and straight question which in my opinion is not being answered by IT silos in the enterprise. The modus operandi has always been to recruit consultants, who have appeared in these flavours:

  • ITIL consultant version one - rename the help desk to a service desk, changes diddly squat, flogs some "compliant" software and exits stage left.
  • ITIL consultant version two - says that ITIL is too difficult to fully implement, and states that the renamed help desk is all about incident management. Sprinkles some change management, declares that this house of cards is now standing and exists stage right.
  • ITIL consultant version three - has had a Damascus experience and declares the CMDB as the monkey wrench that is going to tighten all bolts. This is very lucrative as the service desk software that has been flogged is turned into a JATO Rocket Car, with a pimped up database. Consultant performs a Britney Spear's ditty, Oops, I did again, centre stage, before trying to escape the lynch mob, who being substantially poorer, have turned ugly.
  • ITIL consultant version four - a reformed beanie who says it's all about governance. After death by PowerPoint, its death by paper. Collapses on stage under the weight of their own bureaucracy.

What problems are YOU addressing? We return to this question and analyze it further. To assist in dissecting the question we can take some direction from Rudyard Kipling, who in The Elephants child, said: "I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who." Thus,

  • What is the problem?
  • Why is there a problem?
  • When have the problems happened?
  • How have these problems occurred?
  • Where have these problems manifested?
  • Who has been experiencing these problems?

In this context we see why the cart has been put before the horse in ITIL enterprise deployments. The ITIL horse is problem management, the rest is the cart!

If the problems in the enterprise are identified then the ITIL show can start putting some rubber on the road. Many consultants and vendors handle problem management as the ugly sister of process management. As an example, there is no root cause analysis software available for Information Technology. So, what problems are YOU addressing? Here is a tip to start burning some rubber.

The first step to start answering this question is to review major incidents and the major incident process. A major incident is an incident with severe negative business consequences and an important duty of a problem manager is to evaluate the efficiency and effectiveness of the incident management process.

The benefits of this approach are not immediately obvious but it touches largely on financial management. Within IT, the cost base is always the IT budget and it is not easy to prove an investment return on the IT budget base. As an example many ITIL based initiatives add to the IT budget base without a corresponding measurable reduction. This would be true of a CMDB implementation, as an example. The major incident process is crucial as it focuses on business consequences and a measurement of the associated costs of a return to service. This is where a financial justification can be extracted. The costs associated with a return to service influence the business budget base. Light bulb! We are addressing business problems and not IT problems.

The route to these problems are lit up by a crucial component of incident management know as the Expanded Incident Lifecycle. When reviewing major incidents the sources of problems can be determined from the following recorded times:

  • Time of incident
  • Detection time
  • Workaround time (temporary return to service)
  • Diagnosis time
  • Repair time
  • Restore time
  • Recover time (permanent return to service)

How will these help (and are they even recorded in your pimped up database)? Remember we are working on a business financial justification which is all about money! Time is money. TIME IS MONEY! Thus an analysis of these times will clarify the following small sample of potential problems:

  • When is the business being impacted? Is it at recognized stages like month end.
  • Is the return to service being prioritized?
  • Are we detecting incidents quickly? Are the systems being suitably managed or monitored?
  • Are the incidents correctly diagnosed? Is this diagnoses performed within expected time parameters. Are technicians suitably trained?
  • Are repair processes initiated within suitable time limits after diagnosis? Is there a logistics issue?
  • Are restore time adequate? Is there an issue around continuity or dated technology?
  • Does the system start processing and become functional in a useful manner to the business in an acceptable time period after being restored? Are there cumbersome interface issues?

Straight from the horse’s mouth, you now have a set of problem and in all probability the financial justification to correct it. What you need in your cart after this approach might not be what you had previously envisaged, especially if the cart was sold, serviced and specified by a vendor or consultant. And we haven’t even addressed the analysis of root causes which we’ll leave to another blog post soon.

Major incidents and by implication problem management have three broad cost categories associated with them. As can be expected time is an important multiplier. These cost categories are listed here to provide better insight into the financial due diligence required.

  • Repair cost – the cost most often budgeted by IT. This is the down time multiplied by the pro rata cost of the tiger team.
  • Return to service cost – the cost to the business of the associated unavailability.

The above is made up of the following costs:

  • Down time multiplied by population affected and normalized head count charge.
  • Down time multiplied by missed revenue opportunity costs per hour.
  • Overtime and other direct costs associated with the major incident.
  • Soft costs such as customer perception and legal charges or penalties.

What problems are YOU addressing? The short answer should be those that drive the business. This approach will determine whether the existence or not of a service desk, change boards or CMDB are indeed problems as opposed to vendor driven hard sells.

This article was originally published over on LinkedIn: ITIL in the enterprise (the cart before the horse)


Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi