Project Management

Death by ITIL: How IT departments streamline themselves into oblivion

When it comes to your IT shop, don't put frameworks and methodologies ahead of objectives.

You may or may not know that magpies. They are rather large birds from the crow family, with pretty black and white suits, who exhibit an irresistible attraction to small shiny objects, such as spoons, foil, and small mirrors. Most of the objects procured by magpies end up stashed at the bottom of their nests, neglected after the initial feat of fascination.

It strikes me that many if not most departments fall victim to the same kind of fascination, when it comes to various frameworks and methodologies du jour. CMM and CMMI, PMBoK or Prince 2, ITIL and COBiT, Agile (I cannot bring myself to listing its gazillion flavors), TQM and Lean, Six Sigma, RUP, and all that crackle and pop ad infinitum. If you have been in this profession long enough, you know that every few years a new fad diet comes along.

Please don't take me wrong, every IT or management methodology has at least some value to it. Toyota Production System is behind one of the most efficient car manufacturers in the world. Agile, when used correctly in the right environment, helps to create product when the "big upfront design" approach is ineffective or impossible. Key PMBoK or Prince 2 concepts are a must for any project management professional.

What I do find troubling is that IT management nearly always disregards the fact that methodology is secondary to objectives. If only could they ask themselves a simple question of "What are we trying to achieve?" more often! We could achieve results more expeditiously, while avoiding unnecessary and time-consuming undertakings. When the only tool you have is a hammer, everything starts to look like a nail. When the only answer one has to any IT management question is "ITIL," you can be sure that it's not going to end well.

A couple of years ago, one IT leader proudly told me about his department's great success with ITIL. When I asked for an example, he said: "Well, for instance, we used to close tickets without asking the user whether they can be closed. Now we always ask and users appreciate that." If you are in charge of IT Operations and cannot figure this out on your own without ITIL, you are probably in the wrong line of work.

How to paint yourself in the corner using best practices

Whenever I am engaged by an organization to advance their IT department, I often look at the current state with the following two variables in mind:

  1. Operational capabilities. How do internal clients rate IT service? Are outages common? Are people knowledgeable in their respective disciplines? In other words, if this were a standalone company, would they be known as rendering good service?
  2. Strategic awareness. Does the CIO appear engaged in the corporate strategy on par with other C-level colleagues? Is the IT department seen as a valuable asset, an inseparable vital organ of the corporate body? Does IT management and staff understand the business their organization is in? Does IT innovate incessantly, propelling their organization forward?

This approach is similar to application of the Gardner's magic quadrant, except that they use it to look at whole industry sectors and I apply it internally to IT departments.

Here are the four states I usually find organizations to be in, depending on the behavior of these two variables:

1. Morass (Ops -, Strategy -)

The quality of IT service is below par. Outages are common. Business often finds itself in a situation where the technology is seen as a limiting factor. Project management is haphazard and the rate of project failure is high.

The IT department views itself is a support function, akin to facilities management. There is often a strong "them vs. us" sentiment among the IT staffers in reference to the "rest of the business."

This state has been a common occurrence until outsourcing became a norm. If you are a new CIO entering a department like this, be warned (as you likely have been!) that you don't have decades to turn things around.

2. Growing pains (Ops -, Strategy +)

IT services are unpredictable. Outages may be common. Operations may be haphazard, with key tools missing or jury-rigged. There is a sense that "too many things are on the go."

At the same time, CIO is one of the key people within the organization. IT managers have a very good understanding of the core business. IT comes up with solutions that wow their business colleagues. There is a lineup of future projects and noteworthy ideas on a whiteboard.

This state is usually transient and is typical for startups or organizations that underwent a major surgery.

3. Reliable service provider (Ops +, Strategy -)

The department is seen as a reliable provider of IT services, no more, no less.

4. Vital asset (Ops +, Strategy +)

Excellent in what they do operationally, IT staff and management see themselves (and are seen in the same way from the outside of the IT department) as a major catalyst in propelling the company forward. Innovation is a norm and is not a mindless tinkering but a quest guided by excellent knowledge of the industry, keen business sense and the understanding of business priorities.

The CIO is one of the most respected executives within the organization. He or she reports to the CEO and is never looked at as a senior "propeller head" but as a wise decision maker, a strategist and a businessperson.

IT departments that become infatuated with ITIL and that pour enormous resources into aligning with it, will achieve, at best, the third state, reliable service provider. Often seen as the best outcome one could hope for, it is not.

These IT departments will find themselves rather more expensive than before, with new staff - IT bureaucrats - hired to monitor and enforce compliance with procedures.

At the same time, they will have established an almost arm's length relationship with the business, having documented services that they render and SLAs that come with it, much like a third-party vendor. Their service, even if it is excellent, is now a commodity.

On top of that, they will have lost their flexibility and agility, due to numerous documentation steps, signoffs and approvals - even though they are there with a good intention to protect the integrity of the vital systems.

In today's economic environment when responsible fiscal management (often, ruthless cost cutting) is a must, the only possible question that can pop in the head of a CEO in this scenario is "Can I not get a comparable service that wouldn't cost that much?"

They can and they do. Having painted themselves in the corner by following a "state of the art" methodology, many IT departments stand a good chance of becoming history.

On the other hand, those IT departments that exhibit both operational excellence and strategic awareness, find themselves completely immune to outsourcing, because they are not merely service providers, they are an indispensable part of the organization's economic engine.

What kind of IT department are you running today? What is your vision for your organization's future? How are you going to get there?

I have recently co-authored a white paper, which may outlines the vision and ideas that will help you to turn your department into a vital asset. You can download "Transformation or Travails: The imperative for IT's shift from support function to strategic asset" by clicking this link.

About

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations.

49 comments
ITSM Consultant
ITSM Consultant

ITIL is a set of guidelines based on best practices gathered from the IT industry. It is not a 'methodology.' This being said, it is what you make it. The purpose is not to be rolled out verbatim straight from the book but to be adopted and adapted. This way, every organization can take just what it needs to achieve its ultimate business objectives. Unfortunately, what's occurred over the past few years is that every organization has jumped on the ITIL band wagon just because everyone else was doing it. I've heard this over and over again from my clients. They want to "implement ITIL." But when asked why, they have no real idea as to exactly how ITIL processes will help their organization. But just like the latest software, they must have it. Much of this, unfortunately is fueled by inexperienced consulting firms, also on the band wagon. They prey on their clients lack of knowledge to rack up their billable hours. This inevitably leads to wasted efforts, failed processes and more anectdotal evidence that 'ITIL just doesn't work.' A thoughtful and step by step approach to IT Service Management is what always works best.

Beyond20
Beyond20

"Now we always ask and users appreciate that.? If you are in charge of IT Operations and cannot figure this out on your own without ITIL, you are probably in the wrong line of work." I couldn't disagree more. ITIL isn't meant to be "revolutionary"; it's full of simple, common sense practices. Just because something is simple doesn't mean it's necessarily easy. Still, there are easy, "quick wins" to be found in most organizations, many of which are described in ITIL. The existence of these "quick wins", regardless of their source, is not always a reflection on the skill of the IT management team. Furthermore, while many of your remarks are accurate when applied to ITIL v2, version 3 does focus on running IT like a business, and achieving "stage 4". Regards, Brian Flora Principal Beyond20, LLC. http://www.Beyond20.com

paul.gunovsky
paul.gunovsky

This principle applies right across the IT spectrum. In the past as a writer for an IT/Ops publication for the Financial Sector I wrote an article entitled "Methodologies - Tool or Mantra" highlighting the fact that the methodology is just a tool to support good management not to replace the lack of it.

GlennHughes
GlennHughes

Nice one Ilya, this is one of the best articles I have read on this forum and this topic. The opening comments about the various methodologies are so true but seldom realised. It made me laugh out loud. The various comments are also spot on about the pitfalls of ITIL. Having 'done ITIL' in various companies I've seen many of these issues. Finally, many of the comments seem to be from experienced IT pros with a common sense and pragmatic view of ITIL and other frameworks. Anyone who wants to create a new group of like minded people who see the benefit of ITIL 'et al' but understand how to implement it and keep the end game in mind let me know.

Dyalect
Dyalect

Fancy and expensive square pegs, that NEVER fit into round holes. You want to implement you have to tear down your processes and build from the ground up. They do make catchy letters you can put next to your name when your "certified". Makes sense, but seems like a convoluted way to say. 1) document your work 2) have controls and monitoring in place for projects 3)organization and accountability. -- These three are free!

jmarkovic32
jmarkovic32

When a key IT person has to play both a strategic AND operations role something has to give. Our company seems to have a grip on strategic planning, but operations are spotty. We're constantly putting out fires because we don't have the staff to be proactive. We're not young either...we're in our 40th year! However our IT department is young as an actual functional business unit. However, at 3 people strong (or weak), with 3 distinct role, we don't have the manpower to be operationally effective.

rlcallaway
rlcallaway

ITIL is a British creation -- like most European processes it is bureaucratic and labor intensive. Even if "properly" implemented it is costly, rigid, inflexible and will require more staff. This article tells it like it is. The same is true of all of these "fad" management techniques. There is no Magic Bullet.

carringtonl
carringtonl

If ITIL is implemented correctly, ITIL can and will produce measurable results. ITIL is all about aligning IT with the business' objectives, priorities and requirements. I've been in the IT consulting business over 20 years and hear the same arguments no matter what methodology we're discussing. A major point is being missed--if you want to improve the processes used in your business (whether ITIL, CMMI, or whatever methodologies you're adopting), get involved--suggest improvements and make changes to it--don't just complain about it. No process methodology should be taken wholesale--it has to be customized to fit the business and its goals and objectives. Even in the beginning of ITIL implementation, assess what you currently have and keep what works. Then, put the processes in place that are needed to achieve the vision of where you want to be, whether those are ITIL, PMI, CMMI, or whatever. Then, the process has to constantly evolve/improve and provide you with returns or why do it? And, you need senior management buy-in as well as involvement from all practitioners across the organization in order to ensure success. Capture benchmarks before and after implementations to ensure you're on target and you're getting your expected ROI. ITIL is proven and it works but you have to implement it the way it makes sense for the particular business & environment.

randisc49
randisc49

After 60 years on this earth I thought I was the only one out of step. I'll never think that way again. I will sing to the top of my voice "The King is in his all together"

ChicagoJCB
ChicagoJCB

Very interesting perspective, Ilya. I do find after many years of consulting that companies are always looking for the easy way to solve their problems, and unfortunately most methodologies do advertise themselves as a solution. But you are right: they are all merely tools and are useful only to the extent that they support company objectives and, possibly, provide some structure where it is needed. Most advocates of one methodology or another are scandalized at the idea of picking and choosing, but in fact that's a great way to do it. The bottom line is, the tough decisions still need to be made.

df3859
df3859

I had to close 2 superior Helpdesks in a consolidation effort to create a single Service Desk. Managers replaced by non-mgnt personnel - far less technical and not allowed to provide pure Tier 1 resolutions. Why you ask? Some hot shot decided on ITIL but never looked deeply into the pool to understand the existing specializations and how our internal employees would be affected.

doug.brunner
doug.brunner

Nice article. We should definately always keep in mind "what are we trying to acheive". Has anyone ever found themselves working a project titled something like "Implement (insert name of ITIL process here)"? It lacks a certain sense of "why are we doing this" doesn't it.

grayguy_mk
grayguy_mk

I agree with your point. Currently I am suffering from a management team who have implemented PRINCE 2 so badly, that PMs spend more time adhering to a flawed governance process than they do managing projects. ITIL, also can be implemented in such a way that management reports become a major deliverable rather than the service they are meant to be describing.

jmgarvin
jmgarvin

Too many organizations miss at least 2 of the 3 points you've mentioned though and need a framework for guidance.

gcaussade
gcaussade

My last ITIL implementation was in a state government org. The first group only had 4 people and much of their time was fire fighting. The first we did was implement Change control. Properly implemented, unlike many of the posts you see here suggest, it saved them a lot time, and now they: 1) Knew what everyone else was doing 2) Properly planned all critical changes, so there were far less emergencies. 3) The customer was very satisfied and happy. 4) All the staff became customer-focused and communicated changes prior to making them with the customer leadership. Wish you well!

ben@channells
ben@channells

It?s based on a history of failures from major IT providers and lessons learned combined best vendor practice. The biggest lesson NOT learned is NOT to outsource TOO much and lowest cost provider does not provide quality required or the reliability needed (See media for major IT data losses)ITIL is not a major issues for UK government departments and not widely used see media for Major public IT program failures. IF IT get involved in the ITIL process it can lead to large cost saving and fine tune already working models, remember it a guidance framework NOT a do to list you adapt it to IT. However it the wrong hands it can be used as a heavy hammer to smash a square peg into a round hole, where the consultant do not care of the damage just to get the project done and a tick in the box. Much of it is sensible IF you had the time to think about it but you senior managers did NOT think of it or give YOU the time to think about cost saving an operational management. Many outsource providers see ITIL as a check list and a number of process that need to be followed by an off shore operation, and the script is followed rigidly. This leads to systems and service costing twice as much and taking twice as long (See media for major IT failures). Last year I was working on ITIL implementations at delivered over ?300 million is savings for a telecoms company and recently a SOX service that delivered ?980 million saving and stared a manual reconciliation program that recovered ?9.3 billion

gcaussade
gcaussade

ITIL is a British invention. But, ITIL is simply a framework of best practices. Anyone in IT for a few decades already implemented many ideas behind ITIL several times. CM, configuration management, disaster recovery plan, etc... It is a wonderful "library" to go to and get ideas. The first thing ITIL says is to NOT use it as a rigid system. I'm sorry, but your statement is categorically "false". I'm not British, but since it's an open system that isn't rigid, maybe you'll reconsider European and British thinking :)

petermoy
petermoy

About a year ago, I remember a columnist in IEEE?s Software magazine reminding readers that processes such as those proposed in ITIL can only make about a 20% contribution. The other 80% contribution is from good people with mastery of their technologies, well lead and working in a productive environment. (Common sense?) Why the fascination of some IT management with process based frameworks such as ITIL? I?ve just read SWAY by Ori & Rom Brafman, one of the many behavioural economics books that have hit the market recently and it makes the point that our brains are hard wired to feel justice has been done if a defined process has been followed even is the outcome is bad. I suspect managers are using ITIL processes for this reason.

jmgarvin
jmgarvin

Sure, it is labor intensive at the outset, but you can be on autopilot after everyone knows the processes. As for the bureaucratic, maybe, but I'll bet money you are dealing with the same bureaucracy now, you are just used to it. Plus, it should save on pointless bureaucracy and push documentation and flow. ITIL should never be rigid, it should always be about improvement. If it is rigid, you are doing it wrong. It should also require the same or less staff, once implemented.

edtaaffe
edtaaffe

Many people agree with me privately when I repeat these sentiments but don't have the guts to say it publicly. Business is becoming a victim of bloggers as opposed to interested responsible commentators. ITIL, PMI, despite the best intentions and a lot of well designed processes, they provide a slow expensive wheelchair that robs managers of the ability to walk, but the real damage is done by the jargon that brings communication to a complete halt. Read my recent article here: http://www.thebridger.co.uk/blog/?p=103

grayguy_mk
grayguy_mk

There appears to be a movement within business that says as long as it is a methodology then it must be good. There are a number of things that need to be done before any method is used, and that is ensure that you have solved your problems first. Failure to do this will mean that an organisation will never know if they are being totally affective. The other thing to consider is whether or not an organisation is "mature" enough to take on a new method. Most organisations are not, I am afraid to report

pfarrjam
pfarrjam

Way back when in the dusty days of old it was MBO, and everyone hated it. It sure seems like we're coming back to the same thinking again, and in fact it seems like it makes sense (again)! I agree, the "cult of the methodology" approach is way to simplistic, and the management group who latches onto any particular methodology as a general panacea to cure all an organization's problems was probably doomed long before they chose the methodology du jour. I've got a military background and am a big believer in the power of leadership versus management, setting direction and creating vision, and helping teams build healthy behaviors to create outstanding results. This is organizational health that transcends methodology and process. Death by ITIL is just another symptom when the real trouble lies deeper. Good post - I' like to see more like this.

Tom-Tech
Tom-Tech

Having worked with ITIL a lot I find that issues arising with it are nearly all related to the fact that a lot of people who know a lot about ITIL don't know much about IT. Consequently, a lot of ITIL practitioners take to the ITILisation of a department with an almost religous zeal, changing things that aren't broken to fit the ITIL model. The irony of this is that ITIL doesn't purport to do this or say it's a good idea to do so. The entire point of ITIL is that it is a collection of IT Service Management best practices, as defined by the collective experience of a lot of people over a large number of IT departments, but this doesn't mean that what ITIL maps out is right in every situation. The ITIL zealot will always forget this. I do agree with the authors quadrants and agree that sticking with ITIL makes getting past step three very hard. I would also say however that ITIL, when implemented correctly, can accelerate the development up until this third stage compared to if the department were not using best practice methodologies. The important point is making sure departments don't try and run before they can walk and that they are aware of the concepts, ideas and goals behind ITIL (or indeed other methodologies) before deciding to break them.

steve
steve

I'm an admin guy - backups, storage and the boxes that run those functions, and I have never understood the way that ITIL is implemented. It seems like a general Cover-your-ass exercise to make sure that management can always find a scapegoat, someone who didn't follow the process, whenever something goes wrong. As an admin, change is what I do, and change management is where the sandpaper is against my skin. I've been in IT for almost 30 years, yes I've made my share of errors, but I object strongly to having my changes documented to within an inch of their life, then having to wait for the change meeting that inevitably is a week away, having to sit through an hour of everybody else's change presentations... and then having some idiot manager from outside the area with no idea of the realities of the situation insist on some bizarre unnecessary additional step.... all for something that has a 99+% chance of going correctly and will take 10 minutes. Then they complain that I'm too expensive and send the work offshore. Let administrators do what they do, change things. Help them, make it easier, work to their convenience not management's, and accept that some errors are inevitable. You can't inspect your way to quality, neither can you bureaucratize your way to it. I do not believe this is ITIL's fault. It is the faulty implementation behind it, and the inability to ask that question "What are we trying to achieve?"

Geek3001
Geek3001

I think that the image found in the Wikipedia article, the one with Service Design, Service Transition and Service Operation does a good job of showing what ITIL should do. Because you are dealing with a dynamic environment, you have to constantly go through this 'design spiral' to keep things functional. The IL side, the Infrastructure Library, provides the 'how-to' side of the spiral. Ideally, all elements of IT should be using some version of these 'best practices', within the resource limits of their organization. I first ran across this 'design spiral' concept in an architectural design class. The basic idea was that you go through an iterative cycle of analysis, design and evaluation until you run out of resources OR have the 'perfect' design. Of course, with buildings you have a good incentive to do things right the first time. (That or plant ivy to hide your mistakes.)

gcaussade
gcaussade

Many of these points come from the manufacturing area and don't translate well to IT. One example: I've seen programming groups decide to manually rewrite huge applications - 1 million line of code or more apps. Then only after many months of delays and cost overruns do they bring in an expert at software modernizations. The expert puts in new processes that incorporates automatic conversion tools. These tools completely change the process, it's not just a tool. I have seen many case studies that improve the outcome by 4-5 times. That is a huge time/money savings.

innovative network solutions
innovative network solutions

There are a number of methods we need to take into consideration so that we can solve our problems sucessfuly. I also feel that most organisation and not "mature", which is the primary cause of these problems. How will these organisations know if there work is affective?

gcaussade
gcaussade

I've successfully implemented some ITIL - Change Management (CM) and Disaster Recovery, to be specific in rather "hostile" environments. I look forward to using ITIL configuration management and other areas in the future. I find ITIL and Project Management (like PMI) to be highly beneficial. The proper implementation of ITIL requires a strategic view. I'm not sure why this article separates "strategic". Also, ITIL is a set of suggested "best practices". They are to be modified and implemented depending on the needs and maturity of an organization. I agree that blindly implementing these systems is dangerous. However, the first step in implementing ITIL is making people understand that it is not just another "fad". Part of the process of implementation is having everyone understand the benefits. Still, I've succeeded in implementations because of support from the CEO and upper management. I dislike paperwork and unnecessary systems, and I understand the frustration people have with following some of the procedures. Short story - since implementing ITIL CM, I have left the org and one of the processes was "weakened". The need to pre-plan and document a server change, then receive approval was seen as "too cumbersome". The person who decided not to follow the procedure has now been sidelined to a minor position because of screwing up a major server transition. Had they followed the procedures I had put in place, they would have been safe. Call it "butt covering", but in fact, communicating and receiving feedback on a change is helpful to an org and if it goes wrong, the blame is shared. Also, in my view, ITIL CM is there to document mistakes without blaming the individual. This is critical. I always praised everyone who disclosed mistakes and issues. It is important to blame the process NOT the person. Otherwise, the process will not be improved.

philr
philr

Agreed - If you cannot answer the "Why?" question, in a business outcome oriented way, then your leaders have failed you. ITIL still needs an over-arching framework of governance so that business motivation is known. Applying methodology is always a tough ask. Before hand everyone is against it. Afterwards they were champions of it all the time. If you have leadership and good teamwork then your communications are excellent and you are probably well on the way to success. Methodologies always flourish in certain environments and fail in others. Investigate companies who succeed, for example in the Baldridge Awards, and you will find they probably do well in many other spheres too.

djmorrissey
djmorrissey

THe whole concept or ITIL is to provide a flexable open structure of best practices that you adjust and change to the business you are using it in. What your saying is that something could be ITIL certified - something that does not exist. If your department or company is doing something that works well- guess what: THAT IS A BEST PRACTICE and should be part of your ITIL plan. Almost all issues with ITIL implementatiosn are people who learned just foundations or took the wrong set of training courses to understand the sections it ITIL.

david.hunt
david.hunt

I couldn't agree more with both Tom-Tech and the original article. There's nothing wrong and many good things about ITIL. Just as with ISO9000, you can implement in a way that consistently builds a poor product. I do see many blindly implementing ITIL processes in a blind bureaucratic manner, believing that the tool will fix the problem. We all know a tool alone will never fix any problem. An appropriate tool, correctly applied to achieve the correct objectives will solve a problem. If there isn't a problem, don't spend time and money to turn it into one!

Dr. Funk
Dr. Funk

I wholehertedly agree. ITIL is a framework - nothing else, and in that respect it is benign. The problem lies in the implementation, particularly death by KPI. There is no point monitoring everything you can because you can. If the stats have no relevance or are not looked at there is no point wasting time in keepinng them. You can apply a similar approach to change management - there is no need to document every little change or request if they have no overarching effect on reliability and service delivery. A loose system where everyone know the rules and what is expected of them would, I suspect, be far more efficient than one that requires a room full of docs and admins.

jmgarvin
jmgarvin

It isn't ITIL, it's your process. Changes should be documented, but not all Changes should go to a CAB. Let's take your 10 minute change. Let's say it doesn't go fine. It's nice to have the documentation (if you get hit by a bus or win the lottery), of what you were doing or what you did. As for the CAB, you should have different flavors of changes. This one you describe should never need to go to a CAB. At worst it should only ever need a manager approval. Typically, it should be documented and done. Also, too many companies mudge up Change and Release, so it's this messy spaghetti process. Long story short...don't blame ITIL for idiot managers that created stupid processes in the name of ITIL.

hug.login
hug.login

I couldn't agree more to what you have written, Steve! It is amazing what gets measured just for the sake of KPI's (Key Performance Indicators) who just produce costs but you'll never earn a buck more by collecting all this information!! It gets even worse if Sarbanes Oxley (SOX) is involved. This is usually the end of all logical thinking and the end of common sense.

gcaussade
gcaussade

I knew someone was going to state that it isn't process but technology or leadership. :) It is a valid point. I agree with the posts that warn that simply throwing technology at a problem is fraught with problems. In my example: Poor leadership could then improperly use automatic conversion if, as many are warning in this thread, outcomes aren't considered. But, I used automatic conversion because I know it well. And it IS process and technology, and in most cases it's the same management that decided to change course and use it. In the cases of 4-5 X improvement, you have to change the process and technology. If you just change the technology, the benefit is much lower. And, yes, people have to be trained to use the new technology and processes. By the way, I find it interesting that the Theory of Constraints (TOC) isn't being mentioned. It mathematically proves that improving process without looking at throughput of the entire system will not work. This is the reason many projects, 6 Sigma, etc. fail to generate real cost savings, or increases in productivity. TOC shows that you must improve the constraint. If you improve other areas, you actually reduce throughput. So if you apply 6 Sigma to the wrong area, you are in trouble. Ironically, many 6 sigma black belts don't know about TOC, so don't know what processes to improve. (I'm sure many do, though.) Improve the constraint, or reduce output.

petermoy
petermoy

I'd suggest that your 500% improvement didn't come from your processes but from sources such as: . New Leaders that had a clue on how to attack the task. . Technology. (Automatic Conversion). . Probably training & learning by the staff. I not not saying the following framework based processes hindered the the undertaking but they didn't give you the improvements you claim.

philr
philr

No, I meant Ishikawa but I was wrong. Thanks for the correction, as you can gather it is a while since I was in this space!

gary.vanpoperin
gary.vanpoperin

I believe you mean, Deming said, "Drive out fear." You're right however on fixing the system. For too long the "system" was driven by the technology dictating how things should work. That model broke several years ago. The technology has got to support the business and not the other way around.

philr
philr

You made an essential point. Fear is the enemy of sound progress. The goal is continuous improvement not shooting the individual who stuffed up. Often the "system" has properties that create failure. e.g. demanding that truck drivers work long hours (often illegally). Why blame the trucky? Fix the system or go out of business and good riddence.

gcaussade
gcaussade

I've been using change management, configuration management, disaster recovery, etc. for decades, and I'm personally very thankful there is a group that has put together a set of "best practices", and are open to feedback to continuously improve those recommendation. It is nice to then add that with feedback from staff and industry groups that also have their domain-specific knowledge and recommendations. I agree with everyone's concerns of a zealous implementation of any system. That is very dangerous. Take PMI, ITIL, TOC, 6 Sigma, etc and use them where necessary. The hardest part is developing trust and relationships in any case. Unfortunately, many of the posts slam ITIL as if putting together some recommendations is a bad thing, when ITIL specifically warns about being religious about implementing any of it's recommendations. It's like calling an agnostic person religious! I make money because my customers speak to references that have saved a lot of time and money. It is helpful being cautious and negative at times, but telling people what not to do is less helpful than showing them how to do it. I think some of the negative posts on this thread show examples of poor implementations or the subset of users that have not understood ITIL. I've seen both. Even great ITIL implementations have some end-users complaining that it's not working. But, the CEO, management, and key players are all saving time and money. You can't make everyone happy. Again, I do think cautious notes in this thread should be read, but only as long as the positive aspects aren't ignored.

steve
steve

"Best practices" is like motherhood or patriotism, how can you argue against that? Labelling something as best practice is a way to steamroll opposition and appear to be a deep thinker and strategist but in fact abandoning individuality and running with the crowd.

gcaussade
gcaussade

Totally agree. I like the warning the article gives, but I'm concerned because it gives some people a reason to bash it. Arguing against "best practices" isn't really a very productive endeavor. I guess people are seeing poor implementations and feel frustration. It's the people implementing, not ITIL.

gcaussade
gcaussade

You mean these unsuccessful companies: Microsoft, Barclays Bank, Guinness, Procter & Gamble, Telstra, Fujitsu, and Hewlett Packard. There's hundreds more. And, as someone else said, ITIL is part of ITSM. I think Change management, problem management, configuration management, disaster recovery planning are critical components for nearly any good IT dept. Not sure why it's so boring if you like efficiency. On the other hand, it really isn't anything "new"... so yea, it could be a "yawn". That's why I find it funny people are attacking it. It's just a lot of companies getting together and agreeing what worked for them. For some reason people fear that? I don't blame them for being annoyed with consultants that make a religion out of it...That's not the intention.

jmgarvin
jmgarvin

It stand for IT Service Management and it encompasses things like Incident, Problem, and Change (among others).

mike_patburgess
mike_patburgess

These concepts were around in the early 1980's and if memory served me correctly, one of the guises that it came under was ITSM which of course never took off. Fast forward to today and the ITIL bandwagon. ITIL is a bunch of manuals written by the British. If I were running a successful business and I wanted to criple my competition, I would make sure that they followed the ITIL processes. Unless there is a compelling ROI to implement this "----"; don't follow it. By all means take the course in case someone asked you a question but for the most part, this too will die as did ITSM... Yawnnnnn!

jmarkovic32
jmarkovic32

Viewing it as a "tool" that can fix IT problems is the first step in streamlining your IT department into oblivion. It's a framework of best practices that will arm you will the knowledge to operate in the best way for your business.

jmgarvin
jmgarvin

Too many people aren't completely sure what they are trying to achieve, let alone what they are currently doing. It takes a lot of introspection and asking your company some uncomfortable questions to truly implement ITIL (or any flavor of process alignment) correctly.