My conversation regarding why ITIL implementations fail continues with Cindy Allingham, Sr. Consultant…

Cindy:  … there is a danger in getting caught up in the improvements and losing sight of the actual operation. I call that ITIL Overload; it occurs when more effort is expended on the process than on the results.

How can we identify ITIL Overload? Here are some symptoms:

Cindy:  Disagreement among IT management about who owns / is accountable for various processes

If no one is sure who owns a function or process, or multiple groups claim ownership, it is pretty obvious that not much is going to get done. With ITIL functions, however, it is even more critical to establish how accountabilities and ownership will flow between the various functions. If the organization is too small to have adequate separation of duties (i.e. the Incident Manager is also the Problem Manager) the process needs to be simplified. If the organization is too big to have a close functional relationship between the various functions (i.e. the Incident Manager and the Problem Manager are in totally different sections of the company and don’t need to communicate) then having ITIL processes is almost useless.   ITIL process improvements realize their true value when they dovetail together.  This dovetailing MUST be encouraged at a senior level.

MJ:  ITIL v3 tries to address confusion of ownership via the RACI matrix (intended to delineate the various ways people can get involved in a process):

·         Responsible - Those who do work to achieve the task

·         Accountable hose who are ultimately accountable to the correct and thorough completion of the task

·         Consulted - Those whose opinions are sought.

·         Informed - Those who are kept up-to-date on progress.

Cindy:  Various processes proceed in isolation (separate tools, data duplicated in multiple places, processes don’t link up or share)

ITIL Service management processes were designed to fit together. They can certainly function on their own, and most corporations initially implement them in isolation because it is easier to do so. However, if the various processes are all operating in isolation, ITIL’s advantages will be lost and the various processes will actually interfere with one another. (Imagine, for example, Change Management and Release Management operating separately.) If ITIL process resources are spending all their time focused on individual functions, and not on making them all work together smoothly, this problem will actually continue to get worse. Attention must be shifted to integration of the processes, and this will result in streamlining.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222.

Michael Jagdeo is Director Recruitment Services for B Wyze Solutions. 

My conversation regarding why ITIL implementations fail continues with Cindy Allingham, Sr. Consultant…

Cindy:  … there is a danger in getting caught up in the improvements and losing sight of the actual operation. I call that ITIL Overload; it occurs when more effort is expended on the process than on the results.

How can we identify ITIL Overload? Here are some symptoms:

Cindy:  Ailing Processes are addressed by layering more processes on top

After a few years of implementation and operation of an ITIL process, IT management often concludes that the process is not working. Either there isn’t enough compliance, the data kept isn’t accurate, or there is lack of customer confidence in it. These are not really problems with the process itself, but in many companies it is easier to identify the problem as such. Instead of taking the process apart and modifying it, often additional new processes are added to “fix” the existing problem. New resources and new functions are added, to take precedence over the old process, in the hope that it will fix the problem. The only thing this will do is result in confusion and a growing need to simplify the process. It is better to take the process apart and examine why it isn’t working, or whether the real reason has to do with other conditions in IT.

MJ:  It sounds like process myopia (to the extent of glaucoma) ensues over the years.  You get process-focused professionals trying to fix/optimize/add to processes without taking into consideration the business that they’re trying to support.

Cindy:  Documentation isn’t maintained regularly because there is too much of it

This has been a perpetual problem in IT, but in the past few years ITIL has elevated documentation agony to a new level. Part of the problem is that people don’t read these days. But the information explosion has resulted in ‘way too much material to ever be easily consulted. Think of your ITIL documentation as the handbook for how to run your IT department. It’s critical, but it could easily get out of control and include all kinds of useless or obscure information. If your ITIL document focuses on how processes and tools work, change it to emphasize only those pieces of information that are organization-specific and that change most often.

MJ:  Right on!  How many ITIL implementations consist of a phonebook of documentation in lieu of detailed negotiations and mentoring with IT and business groups!?  Additional documentation does not a measurable improvement make.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222.

Michael Jagdeo is Director Recruitment Services for B Wyze Solutions. 

[Note:  This is Part 2 of an ongoing conversation that I’m having with a former VP of IT of a national bank in Canada.  We started talking about why ITIL initiatives have such a low rate of success, and I was truly amazed at the perspective she had to offer.  Click here for Part 1.]

Michael Jagdeo:[In response to Cindy’s email] What I find interesting is that the core ITIL processes of Incident, Problem, and Change Management aren’t practiced very well at many organizations.  Some organizations go through ITIL consultants in various forms and still don’t have these processes down.  

In frustration, I wrote a blog on it, actually.  http://www.bwyze.com/blog/implementing-incident-management-like-a-marketing-guru/.  I’d love to hear your thoughts on where ITIL consultants/IT departments have missed the mark.  What are they doing wrong? 

Cindy Allingham –

Your blog, specifically the article on Implementing Incident Management, touched on an idea that I want to expand on, to answer your question:  Why Doesn’t ITIL Work?

To begin with, keep in mind that ITIL is a library of process guidelines. Everyone knows there are no hard-and-fast rules about how to organize, or what jobs need to be done. Implementation of one process, such as Incident Management, can be relatively easily and cheaply done. And that’s where most organizations get into trouble. They view each process as a stand-alone function that can be built on existing functional foundations.

This is understandable, given that most organizations want to start small and simple, and that’s good. However, true process maturity will only happen with ALL the processes in place and integrated, and that is very difficult.

Take tools, for example. A good incident management reporting tool includes a database and an easy way of entering data uniformly, and it is pretty difficult to get IM going without it. Many organizations purchase and implement a tool for one process without thinking how they will furnish and integrate the other processes. Change Management, Problem Management, Release Management, Config Management, and almost all the other ITIL processes need to be linked by such a tool. To do that up front, however, is extremely costly and requires a lot of planning. Most organizations cannot justify that cost and effort all at once, so they start piecemeal.

Functional flow in the organization is critical, but is probably the most poorly understood area when putting in ITIL processes. However, if you get it wrong you will get situations like this: Incident Management and Help Desk analysts are viewed as incompetent, lazy and uneducated because they cannot seem to stop the rising tide of incidents. No matter what they seem to try, the numbers just keep going up. Project and development teams have no relationship with IM and HD, and just keep developing new great stuff, but the old stuff just never gets fixed. This is all blamed on the Service areas.

However, the development areas do not include impact assessments on their projects, to verify that the new products and services aren’t going to introduce new problems, and to make sure that the Service areas know how to fix the things that break. This is so common, many IT managers are aware of it, but getting it to change is tough. I suggest that, if the blame for rising incidents were placed on developers they would be quickly reduced, but most of the time development functions reject any involvement in service.

It may be, also, that consultants and vendors have encouraged organizations to place very high expectations on ITIL. Many think that, provided ITIL is “installed” properly, all the IT service problems will disappear. But remember, ITIL is merely a collection of process guidelines, so it is still necessary to choose appropriate tools, provide appropriate levels of resourcing, put the effort in to integrate all the processes, fine tune each process in accordance with your organization, and make sure the right groups are accountable.

Senior IT management should, perhaps, also consider whether they have given process owners the right level of authority. For instance, the Incident Manager is usually a first-line manager in the service-side of IT, but has no authority to stop or delay projects, reject new product implementations, or challenge strategic plans that might result in increased incidents. Unless they can do this, they really don’t have the authority they need to be accountable for Incident Management. A way needs to be found to have that in place.

ITIL material and consultants know all of this, and try to convince their customers to do it properly, but more often than not, IT senior management derails or truncates processes to fit the organization. Cutting costs, holding the line on staff numbers, and keeping authority centralized are usually on the agenda, but these are all counter to what ITIL needs to work. Organizations who find their ITIL processes aren’t delivering the value expected will need to get some expertise to re-assess, possibly streamline or re-implement, and shift the ownership and accountability for the key functions. Should you hear an IT exec insisting that they know ITIL well enough to do it themselves without outside help, you need to ask yourself again, Why Isn’t IT Working?

MJ is a Director at B Wyze Solutions.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222

I’ll use my blog posts to share interesting ideas/frustrations/stories from my conversations with ITSM Management.

Change Management Automation
1.  Manager created the change process.
2.  In Heat, he designed the entire process in the tool, from proposing change and linking it from an incident ticket, holding all RFC-related documents like test and back-out plans, to asking CAB (Change Advisory Board) members for approvals, etc.  
3.  A report on all approved RFC’s would be run by the CAB Lead before every meeting.  Therefore, the CAB meetings were concise and to the point.
4.  Changes given to Release Management.

How to get Developers to adhere to your baby, the Change Management Process
1.  Instruct them on change process.
2.  Watch them not follow it.
3.  Redirect!!
4.  Once they start seeing that less production environments get escalated to them, and in turn they can work on the assignments they would like to instead of firefighting, they will buy in even more.  Remember that 50-80% of incidents in production are caused by ill-managed changes.

Enhancing Buy-in & Adoption for Process Changes
1.  Create process
2.  Bring everyone in the room and show them how the process works operationally in the tool they’re using.
3.  Ask them to poke holes in the tool.  Too often training happens and the technical staff go to lunch and tear apart the process.  This way, you can capture the constructive criticism from the process executors and make them part of the process reengineering.
Institutionalizing process changes, especially when it comes to Incident, Problem, and Change Management, does not occur when documentation is created.  Too much time is spent documenting.  We’re businesspeople, not Lead Editors for an ITIL newspaper.

MJ

Often times when things aren’t going quite right in IT, people are quick to blame technology rather than the people or the existing process. In my experience, most mid to top tier ITSM tools can be modified to meet business requirements, rather than investing in new technology.This brings me back to the original question which comes first, the tool or process? In order for an ITSM tool to function effectively, it must enable a robust process. ITIL, Cobit, Six Sigma…..it doesn’t matter, it just needs to follow a best practice framework that is applicable to the organization.

Once the process is defined, then start planning the tool implementation or upgrade (rip and replace isn’t always the answer). Remember to start with reporting requirements first. Often times, if the data isn’t going to be diplayed in a management report, it doesn’t need to be captured in the tool.

Last but not least, in the spirit of continual service improvement, process always needs to be reexamined for improvements. When process is updated, don’t forget the tool!