Project Management

Video: Five reasons why ITIL implementations fail

Lots of organizations are jumping on the ITIL bandwagon to improve the management and efficiency of their IT departments. This episode of Sanity Savers discusses the roadblocks to implementing ITIL and the ways to overcome them.

Lots of organizations are jumping on the bandwagon of ITIL hoping to improve the management and efficiency of their IT departments. Unfortunately, many are ill-prepared to deal with the challenges of implementing ITIL.

This episode of Sanity Savers for IT executives discusses five real-world roadblocks to implementing ITIL and the ways to overcome them.

For those of you who prefer text to video, you can click the "Transcript" link underneath the video or you can read the original piece that this episode was based on: Top 5 reasons why ITIL implementations don't happen by the book.

About

Jason Hiner is Editor in Chief of TechRepublic and Long Form Editor of ZDNet. He writes about the people, products, and ideas changing how we live and work in the 21st century. He's co-author of the upcoming book, Follow the Geeks (bit.ly/ftgeeks).

43 comments
Steve Romero
Steve Romero

Some great points Jason, accompanied by some sound recommendations. Though there are good insights in this post, you have only touched the tip of the iceberg. I will make it even simpler - the reason most ITIL implementations fail is because it involves substantial process and massive cultural change - and few organizations are equipped for change of this extent. If ITIL implementations have any chance of success, the Enterprise must be have command of two disciplines: process management and organizational/cultural transformation. I continue to find very Enterprises that have an appreciation for the criticality of these disciplines and even fewer that appropriately invest in mastering them (or even having a basic command). Process and organization changes are hard. Period. Add the dozens if not hundreds of other variables associated with implementing ITIL and I expect most organizations will fail - and then blame the framework. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

dbecker
dbecker

For those who did not have access to the video, there was one part about "tools" showing a guy with a sledgehammer. It seems so... so... well... let's just say that it seemed like the right tool for the right job!

clixandru
clixandru

You touched pretty much the big issues. I think overall most of the problems are arising due to the fact that IT is seen as an appendix of the organization rather than a vital part of it. One thing is to blame a headache due to lack of medication and a different thing is to realize that your head is a part of yourself and there must be reasons behind the pain and beyond medication. Ultimately, the key metric is the amount of work to be done. IT is the nervous system of a company. When you are working hard with the brain, you are doing it wrong. The right IT is the one that does not need to work hard, at least to some of us.

jkrowe1
jkrowe1

I am considering using ITIL on a Base Operating Services contract. Can anyone tell me if ITIL is well-suited for this use, and if it is, what is the best way to implement it? Or where I can find some existing material that establishes a "yellow brick road"? CKR

dbecker
dbecker

1) ITIL is a framework: It can tell you what and where, but not necessarily how -- it is not that process oriented until you get to Service Operations; it simply gives definitions of what is. 2) Organizations need more than a framework: At bare minimum, Project Management is needed -- better, the ISO standard. Certainly, ITIL can show the flow, but implementation needs process. 3) Not even IT supports ITIL in most organizations. Most of us who have come from the IBM Mainframe environment find ITIL concepts quite familiar [although it doesn't help much taking the test for certification with all those downright illogical questions which have nothing to do with ITIL]. If IT doesn't support ITIL, what chance does the rest of the organization have? Our ITIL instructor was SHOCKED! SHOCKED! I say, when I showed him the Agile Manifesto. Agile uses exactly the opposite principles from ITIL to accomplish what it does. Unfortunately, IT is an armed camp here: Developers use Agile and the Operations folk use ITIL. [For those who aren't clued in to Agile, let's just say that the key is to throw away process, throw everything up in the air, and make continuous unplanned changes without any planning or discipline. Agile works because the customer thinks he or she is getting something for nothing. Think endless rewrites, because there's never time to do things right, just to do things over... and over... and over....] Ironically, ITIL seems to work best when it is in place and budgets are downsized: ITIL will save money in the long term -- but then, you have to convince IT first and management later that is the case. The solution to #3 is to have the IT staff take the class and be certified with the ITIL Foundations class. Hopefully, at least 30% will pass. The biggest problem of all is that people don't know what ITIL is, let alone what it can do for you [what?! we have infitesimally small failure rates because we have a framework!?!], and IT, these days, seems to be the most clueless of all. In the end, we can blame ITIL failure on the Boomer phenomenon of "Have your say and go your way" -- nothing gets done because a framework is just too structured and process is boring [the same kind of boring as not having a car accident because the auto is well tuned and well maintained and the driver has kept himself fit]. Side not: Jason, forget spinich and find another food. Spinich has oxalates in it and while the body does need SOME, in excess [and spinich has the most naturally occuring] it seems to be involved in the production of kidney stones, interferes with the absorption of iron [ironic because spinich is deemed a source of iron], interferes with the absorption of calcium, and, in severe cases, in excess may cause death. This is not something a five year old needs while attempting to grow strong healthy bones. As to what you may choose as an alternative? Good luck!

pjboyles
pjboyles

You missed the number one reason, senior leadership lacks the fortitude to actually take the steps required to implement ITIL. Without the support and funding required, no implementation or change will happen.

pdadams
pdadams

Good insights. If ITIL fails, what are the alternatives? CMMI? ISO? Chaordic processes (those that appear to have order but are merely chaos re-arranged)?

SunView
SunView

Great video...so many good points! Our company has an ITIL-based software, where all the workflows are ITIL compatible out-of-the-box. So many people who are looking at our software don't understand that it is hard work to really make ITIL stick. Our software is a tool that helps, but it takes more than just a tool. Thanks for pointing that out...

jmgarvin
jmgarvin

I can tell you how many companies think the tools they drive ITIL processes. That's a completely backwards way of looking at things. The process should drive the tool and if the tool doesn't fit YOUR processes, it might be time to look for another tool. It irritates me that companies won't change their processes too. It's a cultural shift and it requires a lot of effort to train the staff, but the main part it MUST be from the top. If the execs don't push ITIL down, it'll never gain traction. ITIL is a lot like spinach to a 5 year old. You don't want it, but it's good for you and you need it.

nikwebber
nikwebber

URL to video linked back to the text page with the URL on it. Nik Webber

vyasak
vyasak

Thanks.. Made it sweet and simple..

ramamamidi
ramamamidi

Good one... yes, these are the major genaral road blocks. Others and most common are 1. going for a BIG-Bang approach. 2. all ITIL wants is to align your current process towards common and repeatable processes. But this statement is over carried. Many companies or individuals stay with their process don't want to change or even align to ITIL best practices.

amitprof
amitprof

This was a really nice presentation ,Jason .I have been actively following other presentations. No doubt they too are very informative but this one really handles summarization of descriptive information on this topic with optimal clarity. Thanks again

kgc
kgc

Supremely well suited I have used ITIL in many service contracts and it is very well suited to the purpose because it gives you a clearly understood baseline vocabulary. - Use Service Catalogue / CMDB to define the services that you require. There are some good tools on the market to help with this. - Use Change Management to control the inevitable evolution of the services (Interfaced to catalogue / CMDB) - Use service desk and IM/Problem Management to define what to do when things go wrong and how to improve. Include targets for performance and improvement and chase them hard. Allow the supplier to share the benefits of improvements. ITIL helps to do this. When defining services do not get drawn into the trap of defining "Service" as availability /throughput of individual technologies and components. Define a service as what your business needs to do a day's work in a day (e.g. "Process 10,000 lines of telephone orders in 5 hours") and let the supplier decide how best to achieve that. Hint; I recently renegotiated a contract for a server farm of 200 servers which could achieve the target of 99.5% average availability in the original contract, but in the wrong circumstances could at the same time have left the on-line booking service off the air for 30 days. ITIL is common sense. It is what we all know; it just makes it easier to express.

kgc
kgc

I ahve used ITIL in many service contracts and it is very well suited to the putpose because it gives you a clearly understood baseline vocabulary. - Use Service Catalogue / CMDB to define the services that you require. Ther are some good tools on the market to help with this. - Use Change Management to control the inevitable evolution of the services (Interfaced to catalogue / CMDB) - Use service desk and IM/Problem Management to define what to do when things go wrong and how to improve. Include targets for improvement and chse them hard. Allow the supplier to share the benefits. ITIL helps to do this. When defining services do not get drawn into the trap of defining "Service" as availability /throughput of individual technologies and components. Define a service as what your business needs to do a day's work in a day (e.g. "Process 10,000 lines of telephone orders in 5 hours") and let the supplier decide how best to achieve that. Hint; I recently renegotiated a contract for a server farm of 200 servers which could achive the target of 99.5% average availability but in the wrong circumstances could at the same time have left the on-line booking service off the air for 30 days. ITIL is common sense. It is what we all know; it just makes it easier to express.

jmgarvin
jmgarvin

We use both SCRUM and ITIL and have never had a problem. Agile development doesn't mean making continuous unplanned changes, it means making sprints that follow the product and sprint backlogs. Don't forget that the burn down chart is a formalized view of what the development should look at/like. Agile development also focuses on continual service improvement, just like ITIL. ITIL is long term, while agile is short term.

jmarkovic32
jmarkovic32

Some IT infrastructure folks like myself are fed up with all of these acronyms and all of these competing standards that sometimes contradict one another. There's no difference between having TOO MANY standards and have NONE. No difference at all. Why can't we just focus on having ONE agreed upon standard for IT, one set of accredidations and one set of certifications and licensures? Because getting technology folks to agree on something is like herding cats. I don't know why that is. Maybe it's because IT is so vendor-centric. I'm not stating my displeasure with ITIL, I'm just frustrated that ITIL isn't the defacto standard. How many competing standards does the medical field have? Maybe it will take rogue A.I. Terminators that kill millions of people before someone steps in and says, "We need to have one set of standards and one set of rules and anyone that doesn't abide by it should be isolated and discredited!"

kgc
kgc

ITIL does not fail; implementation of ITIL fails. Over the last 20 years I have been involved in dozens of impementations of ITIL processes and improvement initiatives for existing ITIL processes. To be worthwhile you must know why you are implementing and you must know how to recognise success. Key factors are - Management commitment. You need authority to implement and administer successful ITSM processes, and that can only come from the top. Get management buy in before you start or you will fail. - Measure before you start, measure as you go along, use the differences to guide you and to demonstrate to your management that you are succeeding (and if you do it properly you will succeed). Keep measuring, keep improving your targets. - This is not a project. Initiating implementation is a project (gather facts, obtain funding, train staff, develop and implement processes etc.) Projects have a beginning and an end. But ITIL is a way of life. As with all service as opposed to project activities it is iterative. With the right commitment you will get better. Good luck.

jmgarvin
jmgarvin

No other process will succeed. The problem at that point usually means it's a cultural problem, not a process problem. My suggestion is to look at CMMI, ISO, ITIL, Prince, COBIT, etc and see what fits your needs, but understand that ITIL can work as a wrapper to all those processes.

KnappIT
KnappIT

Great job, Jason! Thanks for the video, and thanks also for posting transcripts. And great reply, jmgarvin. You nailed it. I'm an ITIL/ITSM trainer and consultant. When I hear potential clients describing ITIL as an IT-only initiative, a gigantic red flag goes up. It can't be an IT-only initiative; like you (jmgarvin) said; it's got to come from the top down. Let's think about it: ITIL is simply a set of ITSM best practices. ITSM = IT Service Management = The way we manage the services IT delivers to the business. There's gotta be open and honest communication and support from/between both the business and IT camps. This is not an easy task (hellooo, understatement). I also raise an eyebrow when an organization says, "We're implementing ITIL; we've given ourselves N months." Huh? What does "implementing ITIL" mean? What are your goals? What challenges are you trying to solve? The phrase "implementing ITIL" implies that there'll be an end someday-- a day when you'll wipe your hands on your pants and say, "Whew. Cross that off the list, we're finally done." Nope. Implementing ITIL is like taking piano lessons: you're never "done" unless you choose to stop. Even the most successful concert pianists still take lessons... because standstill means decline.

jasonhiner
jasonhiner

Love that analogy. I'm going to use that.

darpoke
darpoke

I think there's an element of that sporting phenomenon involved where you have a system that youknow somehow works - based on results - but you have no idea how. So you get the situation like with many successful athletes or sportspeople where they try and preserve all the conditions that led to their victorious turning point. These can be lucky underpants, or eating the same meal, or making sure they get laid (or abstaining altogether), or anything. Nothing appears to be illogical when adopting this superstitious appproach - if you think it contributed to your success you'll do everything in your power to make sure that condition is present next time you need to prevail. Computing is sufficiently complex to defy the ability of many people to fully understand it, and so it can often (I've found) be subject to the same approach. Running a disk scan every day to prevent your HDD crashing. Restarting your DSL router when your connection hangs or fails. Thinking you're safe from HD loss by keeping material in a different partition (laugh, but that stung me at the end of last year). It's not that long ago we were offering sacrificial blood to our fields to ensure a decent harvest for the year. Perhaps it's in our nature to appeal to invisible, irrational forces. The alternative is to sit on our hands and wait for it to all go wrong. What a species! :-)

jasonhiner
jasonhiner

I appreciate the feedback. The whole with idea with these videos is to provide helpful, actionable information (in fact, that's the idea behind everything we do at TechRepublic!)

toysarefun
toysarefun

Where I work it's a free ticket for management to run wild and use ITIL as an excuse for every little change, whim, expenditure, process creation, process elimination, outsourcing, contracting, and the list goes on. Success has allot to do with leadership, so I would answer no to the challenges of implementing, this same thought has been iterated by several posters so far. Our company is on our 2nd ITIL implementer guy, he's been here 6 months and not a word or email yet. Sometimes we hire contractors and once they figure out how bad management is they just soak us for as long as they can. We've spent millions on ITIL implementation with nary a measurable result that I've seen yet.

Oldmanmike
Oldmanmike

I'm not able to watch the videos here at work, as our web filters block it. I'd prefer to just read the articles that are provided. I understand there is a Transcript button, but the window the transcript is presented in is small, and the formatting isn't a "eye-friendly" as the normal printed articles. Would it be possible to present more of a full-screen view option for the text, similar to the older posting method?

dbecker
dbecker

Agile and ITIL don't really work together because the fundamental core of each is totally opposed to the other. This is one of those "We can make these work together" measures that contains within itself unresolveable cognitive dissonance. The base problem is a total lack of long term planning for Agile, wherein Agile comes to value: Individuals and interactions over processes and tools; Working software over comprehensive documentation. And at the end of the day, ITIL is all about processes and tools to help insureconsistency -- thrown overboard for image over substance and, at the same time, no one has time for documentation because the applications are so "intuitive". And, oh, by the way, the software doesn't work and has to be continuously recast [oops! we didn't realize Cold Fusion would cost so much compared with Java! Guess we should have planned that!] Grouch alert: Had to come in late last night to bring the IBM Mainframe back up because no one [and IT OPS is fully trained in ITIL] realized that the new air conditioner would flip the circuit breakers when we started using our IBM Mainframe tape drives. Just a little lost process there.

deidrea8
deidrea8

This video shows some great reasons why IT has so many problems. I know that I was skeptical about getting an IT service but I worked with http://pmg.com and they eased my fears.

dbecker
dbecker

It just seems to me that the really big reason for differing standards is that some vendor(s) somewhere wants to make big money. If the vendor(s) has (/have) power over an environment, it is a given that the standard supported by the vendor will prevail. It does not matter if the standard will be more efficient, save money, reduce outages. The standard is what the vendor(s) says (/say) it is. Example: Microsoft Exchange; Windows. The second really big reason seems to be that Those in Power use their Wishful Thinking to create both standards and de facto standards. Thus it is, anything which means that Those in Power have to actually PLAN and WAIT and FOLLOW PROCESS is rejected the moment that something promises to be quick and easy -- no matter how well it works and how much less it costs. Throw in "PRETTY" and the deal is sealed. Examples: Agile vs Project Management and ITIL [or how about hundred billion dollar bailouts?]. Living without any responsibility and ownership has appeal, no matter the long term consequences or how messy things get behind the scene [warning: DO NOT! DO NOT! LIFT UP THOSE FLOOR PANELS IN THE COMPUTER ROOM!].

santeewelding
santeewelding

Don't forget smooth. That was smooth, smoothie.

dbecker
dbecker

toysarefun, What you are really saying is that ITIL was never implemented where you work. Add this to the list: "Management", so-called, has implemented "Assertive Incompetence" as a triumph of image over substance to: 1) Silence the critics who keep saying that we don't have any processes in place; 2) Appear to care about "doing things right"; 3) Lie about how the operation is run for political positioning. In the words of Khan in Star Trek, "Nothing ever changes". In the words of the Klingon Ambassador in "The Undiscovered Country": "I see we have a long way to go".

viveka
viveka

One of the good things about TechRepublic vides is that they are always accompanied by a transcript - only thing is they kind of hide it, but once you have found one, you can find them for all as they do use a standard template. My only beef is their advertized white papers all require registration, and that makes me very selective, given that 95% of white papers are very light on content

jmgarvin
jmgarvin

Agile does mean planning. You're confused.

dbecker
dbecker

How hard is that? Just to be clear, ITIL folks do NOT accept Agile as being valid. It's the Sun Microsystems Cowboy shoot 'em up to deceive management and customers that they can have the RAD without paying the price.

dbecker
dbecker

Agile "sprints" are based on the Project Management methodology that no individual task should take more than two weeks -- not a new idea, and one from the Project Management Institute. [The book on Project Management at the Technical College next door costs $96. One wonders if it's worth it, since most places have thrown out Project Management because it "Takes Too Long". Weyerhaeuser Containerboard Packaging was one of those who threw it out. Too bad they no longer exist. And the Washington Community College Consortium thought they could throw out Project Management, but $14 million and 5 years later, the HP3000s are still out there in the hinterland.] What actually happens in real life here is that the customer sits down with the developer and the developer changes things as the customer sits there and watches. If the customer likes it, then the developer implements it. In our case, it's taken three years and 3 FTEs to create TimeTrak -- it continually changes with absolutely no documentation whatsoever. This is not to mention the $10 million for the new security system and the $3 million to go to Exchange with absolutely NO ROI with the claim that it was just "The right thing to do". Lack of planning certainly saves a bunch of time on the front end. On the back end, it has certainly cost us millions of dollars more than it should have and as a result the budget is, shall we say, constrained. Agile is just another form of "milking". What happens is that entire ecosystem becomes more and more fragmented as time goes on. It's like trying to manage the Winchester Mansion. I've watched this methodology for several years now and what happens over time is severe entropy. Agile is the philosophy of the quick fix, building the expectation of the customer that everything in IT is quick and easy. It's the idea that everything can be done fast, cheap and good and you don't have to just pick any two. Long term implications are ignored. Forget SLAs. PIG = Production If Good. You would expect this sort of philosophy from those Yahoos over at Sun Microsystems who developed Agile. If you want their methodologies, perhaps you should look at their results. Management loves to buy into this particular fantasy because they can more easily maximize profits IF IT WORKS. [The US economy is a good example of using this sort of mentality.] And after a time, ITIL simply disappears into the chaos -- not to mention, in any number of instances, so does the business. I personally observe here that Agile is sloppy and careless. And I can say that because it sure didn't take long to install the new air conditioner. Less than two weeks. quite a sprint. One wonders when we will turn it back on again after last night. Doubtless when someone figures how to rewire the power panels correctly.

jmgarvin
jmgarvin

You've got it all wrong. Agile Development falls into the Continual Service Improvement model that ITILv3 has developed. Just because Agile is short term and ITIL is long term doesn't mean they can't live in the same world. For instance. I'm doing a sprint, which means all the Agile Kung Fu. However, once that sprint is finished, maybe I want to implement that whatever is created. That would fall under Change Management in ITIL.

toysarefun
toysarefun

Implement is the word used but it does not fit. ITIL is as simple as forming some kind of recognizable business management practice that can sustain or track more differential IT efforts which are becoming the norm these days. Oh, and getting some of the workgroups working together, very important, which is how places like Apple and Microsoft make a living. It used to be you just called one or two vendors for everything, now we have like 20 different workgroups, load balancing servers, clustering, massive hard drive banks that are basically just expensive junk eating power and keep track of mostly stupid stuff, like money, who owes who what, and why. That's what made tapes so nice, it's an ownership thing. So you spend the wad buying more stuff to keep track of even more stuff, and the world just keeps going round and round, which keeps all us IT saps in a job.

Editor's Picks