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.
Comments
Post a Comment