What does it mean to "implement" or "do" ITIL?

How can we speak of implementing ITIL or measuring the results of ITIL if ITIL ought to be an ongoing (unending?) process of continual service improvement?
These thoughts were stirred by this recent comment:

..."implementation" is not as easy as everyone is led to believe. The word "implementation" is a contradiction to what ITIL is in itself. You cannot "implement" any of these standards or frameworks. They mature over time. There is no placement and completion. The bad taste customers get in their mouth from ITIL or anyother frame work or standard is the expectation that once the consultants leave the benefits will produce themselves shorlty afterwards. Due to it maturing over time at which point will you say ITIL has been a success.

ITIL is indeed not about implementing something new - it is about improving the maturity of existing processes. They exist even if the level of maturity is so low that everyone is unaware of their existance.

However experience shows that ITIL improvements cannot be introduced in your spare time, that any ITIL initiative that is run as part of BAU (business as usual) is generally doomed to fail. ITIL initiatives are more successful if the investment is initially packaged as a project to plan, design and make the changes required to get things going. This makes it easier to fund, it ring-fences resources, and most of all it gets the attention so as to effect real cultural change (hopefully).

Only once this has been done can we move from a capex step-change to an ongoing opex activity to maintain and improve our newly matured processes.

In order to do this there ought to be defined success criteria and measurable ROI (even if this rule is often breached).

It is this sense that we talk sloppily of "implementing" or "doing" ITIL (I'm as guilty as any). We are referring to the completion of the initial measurable body of work to set the organisation on the path of ongoing self-improvement.


Great words!

Altough I completely agree on your post, I think that the great words inside it are

However experience shows that ITIL improvements cannot be introduced in your spare time, that any ITIL initiative that is run as part of BAU (business as usual) is generally doomed to fail.


But what is BAU?

I agree that ITIL initiatives are doomed when seen as an additional task staff have to carry out, but that doesn't mean it should not be done as part of BAU - what it demands is a redesign of the BAU role to make continual improvement part of it. This might also mean surgicaly removing the non-value adding tasks staff are carrying out because their BAU role is badly designed. Making it a project does not by itself magic up additional resource.

Revolution or Evolution? That is the question!

I have seen many implementations of ITIL and most of them fail. Why? Because they are too small, not enough funding and resourcing, targeting processes that are considered hygienic to the business (instead of critical) and they have the tendency to focus on the paperwork. In other words, these implementations choose a more gradual or evolutionary approach where there is a more drastic approach needed.
First, let me begin with stating that I do not believe in ITIL as a manual on how to do IT Service Management. It is to me a guidance framework and helps to prevent reinventing the wheel. It is specific useful for IT organizations that need to become an IT Service Provider instead of a supporting IT department. The only implementation programs using ITIL that were successful (somehow where perceived to be successful by both IT and the Business and by external auditors) were programs that had a revolutionary approach to make a major change in the way the IT department was organized and managed. The main change was to set up a governance to make continual improvement a primary task of management. In other words: improving the IT Service Delivery is managing the IT Service delivery. Managing the IT Service Delivery is Improving the IT Service Delivery. And from this initial revolution (which is painful and creates a lot of resistance first, but that is what a fundamental change is all about) the basis for further evolutionary growth to maturity could be accomplished.
I fully disagree with any statement that you can only accomplish ITIL maturity through a gradual approach. You need to create an IT organization first that can grow. And most IT organizations at the moment can't.

Activity-Based Budgeting as a possible solution

I've come to believe that the central Komittee approach to IT governance is a major hindrance to implementation of good IT practices such as ITIL.

The underlying processes of ITIL, when implemented with a bent towards problem solving, is quite effective at producing internal efficiencies. Unfortunately, it does not produce increased effectiveness of the investment in IT.

Changing the paradigm (forgive me for the 80's word) to include an internal market-based economy approach to IT budgeting helps. By creating a service catalog with service prices based upon allocations throroughly understood by the IT staff and users, we can allow the customer community to advocate for our (IT) activities as "purchasing" decisions.

This transformative approach takes a while to set up, we do it in a 10 month engagement, but the results have been amazing. Customers actually ask for more IT. Budget decisions relate to whole services, not just "cut travel" discussions.

We use it as a precursor to an actionable Service Catalog since it sets up consistent, believable rates. And, it helps IT staff understand what it is they're actually selling - and to whom (the concept of prime and sub- contractors).

At that point, processes can be defined and measured. Delivery steps can be built into a catalog of "standard requests" and fulfilled consistently. All with accountability. Process analysis and improvement activities can be prioritized by costs as well as performance risks. And, that is where increased application of ITIL is used.

Questions on ABC

Activity-based costing/management appeared in response to the criticism leveled against traditional cost accounting. While ABC is still perceived by some as the normative cost system, my understanding is that ABC failed to live up to its promise. I’m curious how you would respond to the critiques which caused few companies to retain ABC beyond a short pilot period:

- Arbitrary cost allocations.
ABC requires subjective selection of allocation criteria, absorption criteria, and volume assumptions. It requires more effort and creates a more complicated costing system, but not necessarily an accurate one. For example, when the production volumes change, ABC cannot predict improvements (e.g. profits or benefits).

- Does not differentiate a bottleneck from resources with excess capacity.
If the organization has an internal capacity constraint, i.e., the demand for its services is greater than its production capacity, the organization should determine the optimal product mix according to each product’s contribution per unit of the limited resource. The “costs” of the various products are not relevant for the product mix decision.

- ABC regards the relation between activities and resource consumption as linear and certain.
This means that additional activities result in additional costs, and reduced activity levels imply cost reductions. However, in reality, there are discontinuities of costs. For example, if a cluster of virtual servers operates at half utilization, neither the cost per user calculated under the assumption of full utilization nor the cost per user based on actual utilization is relevant for decision-making.

Look at it this way: Suppose the cost per user (or service, or application, or transaction, or container, etc.) based on full utilization is $300 but the cluster is 50% utilized. If the cost per user is reduced to $100, for a potential new portfolio of users, it can fill the cluster. Most of the costs are fixed, so the cost per user datum is irrelevant for decision making. A profit & loss per cluster report based on these data is similarly flawed.

In general, the main critique is that ABC (or allocation of all kind) is arbitrary, and the use of any method based on full allocation (traditional cost accounting or ABC) may cause a misleading decision-making process.

What's the choice??

I think ABC is the only functional model that works in a service management context. There are plenty of models that are geared towards financial governance or compliance, but these are mostly irrelevant in managing IT services.

Overwhelmingly I see IT budgets are allocated as "last year +- 10%" depending on the companies growth (revenue and/or profit) or decline. This is no help..

Some direct response;
- Arbitrary cost allocations
"As with all things, you are modelling a reality that is impossible to quantify in absolute terms. Its too complex. Over time you continue to refine the model which brings it closer to reality. A sort of 'differential equation' approach.. All other forms of accounts (particular cost accounting) is just as arbitrary. It only models costs at the very highest level and has no attempt to consider what is happening inside the IT organization.

- Does not differentiate a bottleneck from resources with excess capacity.
"This is the role of some of the other ITIL processes. Change Management and Service Level Management are most notable responsible for resources management and alignment, although capacity management deals with this at a technological level also.."

- ABC regards the relation between activities and resource consumption as linear and certain.
"It really depending on if you apply ABC in the form of a 'standards based' accounting method or a guideline. As a guideline, ABC providing some useful methods and processes. There is nothing that specifically excludes you from modeling resources and consumption in more complex form. It is quite possible to take in a variable scale based on volume and a time based scale based on efficiency or maturity"

I like to consider ABC as the discipline of effort estimation on Project Management rather that ABC as the financial account method of compliance.


Brad Vaughan

activity based=yes; xcharging=no

I am a big believer in activity based costing fit services and transperancy between it and business units, but I would stop before x-charging. X-charging reports to provide cost optimization but the negative effect is it can cripple innovation, strategic value and the minority in favour of the majority.

I think just activity base with transperancy and shared governance of it can work and would consider hybrid of x-charging and traditional budgeting.

It much the same way governments intervene in free markets through regulation and investment , the it economy needs to be managed in matrix fashion.

If you are a believer in capitalistic markets with no intervention , then I am sure you won't like this comment. I should also sat I implemented a x-charge model with great results, it just went off the rails in 5 years. Short term though it had huge benefits in service quality, cost reduction, business buy-in and funds distribution.


Brad Vaughan

Applications in the Service Catalog?

How do you handle application hosting, development, and support in your Service Catalog? Is each application an instance of a generic "hosting," "development," or "support" service offering? Or are applications themselves service offerings (e.g. "user subscription to payments system")?

I framed applications as both service instances and service offerings in my book, but am continuing my inquiries.

Or are your offerings strictly limited to infrastructure provisioning?

Note that the original ITIL v2 "Service Catalog" included things like "Payroll System."

Charles T. Betz

ISP vs ASP services

You provoked a blog post. Here's my view. Thanks.

Exception or the norm

I would never deny that it could not be done this way, but the case for "evolution" is based in the reality of investment vs. return.

A full implementation of the type you discuss is a multi-million dollar, multi-year long process from the outset (don't include the continual process), at least. The tools investment, the job restructuring, the business stakeholder buy-in, are incredibly disruptive and risky. A business would have to be very dissatisfied with IT to believe the investment could deliver a significant return (reality or not). The implementation of a "from scratch" building an IT department is easily equal to a ERP replacement project, and we know how they go..

I just think if you are starting down this path, the battle is incredibly uphill and applicable to very few situations. No doubt it is ideal from the "purest" sense of the word, but the pre-qualifiers are a killer..

Brad Vaughan

Use ITIL to Find the Balance Points

I have worked with clients in small teams..just fixing their own houses, too large multip nationals trying to align everyone.
The approach that I have used always goes back to simple business analysis. Know what the drivers are, the pain points and the desired end state. Identify the strengths of your team, use ITIL, Cobit, Six Sigma, Zachmann etc... to identify and mitigate weaknesses.
Big bang works where senior management is actively engaged, but small steady growth from the grass roots works as well. I have always used ITIL as a compass, rather than a treasure map. working with the premise that most people are trying to do a good job, you use ITIL to align thinking and language.

Identify what is working well, document the implicit procedures, assess the value of the explicit ones and seek agreement. (Its quick and dirty but it works.)
Use ITIL to identify any gaps or missing pieces and fill in the holes.

I have been involved with too many engagements where people say they got their work life balance back to suggest ITIL does not add value. Controls align the work, minimise the chaos and allow people to speak the same language. Once an adequate level (in line with business risk) of control is reached, people are more capable in performing their tasks and sharing their experience.

Just my 2 cents

Horses for Courses


I agree different approaches work for differnet situations. The last big consultancy company I worked for used to do a "Readiness for Change" assessment before doing major ITIL work. Unfortunatly since they only knew one approach to implementing ITIL it didn't make any difference to how they went about the assignment - but it could have done, and in my opinion should have had more bearing on how we worked than the ITIL maturity assessment did. After all an orgainisation that recognises that their ITSM maturity is low is probably more ready to change than one that doesn't.

I think there is fertile ground here in helping organisations work out which approach will really work in their specific situation


it is just the scales that vary

I suspect we are all on the same spectrum, just at differing points.

Even the most gradual of approaches needs some initial step to assess the situation, decide the best course, create some sort of roadmap forward, and create the cultural change to make it possible (acceptance, agreement, commitment, education, support).

On the other hand even the biggest of bangs is a waste of money unless it signals the start of an ongoing process of maintenance, consolidation and improvement of what was achieved in the bang.

So in either case the graph is the same shape - it is just the scales that vary:

Yes, but No, But...

I think at heart we are all agreeing at one level, but I don't think it is a simple issue, and I think exploring the ideas is very worthwhile. For instance it struck me that my experience is mostly centred on the UK, where ITIL is relatively mature but we now have a lot of "me to" adoptors and advisers, and Germany, where somehow they often miss the real point.

As a fan of the Theory of Contsraints I recognise that one of the tenents is that actually production and project environments aren't that different, in that a CPA diagram for a project looks a lot like a production management diagram. Culturally though I feel the project mentality is far removed from the production mentality, and ultimatly I am a product of the production mentality.

The Skeptic's post has made me wonder if there is a fractal element to this. You could envision continual improvement as many micro projects.

The big issue for me though is whether blind adherence to a viewpoint, such as "ITIL must be implemented as a project" stops us asking the right questions about an individual organisation's way forward.

Yes, but yes

I agree that the word "Project" has too many preset expectations in most people minds. There are expectations of a implementation of a "solution" and the only definition of "solution" within ITIL is the whole box and dice (unless you want to implement just one process which most people recognize as folly immediately)

Talking about continuous improvement is better for me. It gives a vision of smaller incrementals with the goal of refinement and not complete replacement. It also has lots of preconceptions, but for me the started point is a better place...

Brad Vaughan

a standalone process is better than none at all

the only definition of "solution" within ITIL is the whole box and dice (unless you want to implement just one process which most people recognize as folly immediately)

ooooh, gotta disagree with that one! It's that maturity thing again. At higher levels of maturity it may well be essential for all processes to be merrily interacting, but at lower maturities a stand-alone change or incident process is a lot better than none at all.

True enough

but I had never heard the ITIL industry presenting a model to execute against "Maturity" until recently..

I have been pushing the continuous improvement approach (through modified SixSigma concepts) to execution of ITIL for a while (from about 7 years ago until 2 years ago) and its always been taken as a unique model.

The ITIL industry has been more aligned to the concept of certification and compliance which is counter intuitive to maturity (for the most part)

Brad Vaughan

SM Maturity is an old concept


Most of the mature ITIL consultancies in Europe have been offerring a CMMI type assesssment service for a long time. They tend to fall down because they don't reflect the need to change behaviours between levels, instead they tend to be based around "keep doing the same thing but more of it" but the idea is there. In fact my Service Manager's course back in 1991 included sessions on process maturity. With a lot of crossover with ISACA many of us are also used to working with the maturity levels within ISACA. ISO/IEC 20000 will over the next few years start to provide guidance on maturity levels for service managment.

Is certification inherently counter intuitive to maturity, or should it be seen as a step along the way?



I should have clarified.. I have no doubt that maturity has existed for a long time.. I would never credit myself with unique thought in this area.. It just got lost in a volume of marketing around ISEB ITIL Certifications and BS15000.. It became about meeting the requirements across all the disciplines to a standard set in theory, and less about real world practice..

Any I should also say, I don't think people commenting on this blog represent the "masses".. ITIL has a community, not unlike the "Certified Netware Engineer" community of 10 years ago.. Alot of people existing universities and high school with certification for something they have no possible concept of applying.. Every man and there dog has a Foundation Cert and is credited as being "ITIL Certified"..

I have run into a large number of people over a large number of beers with a very mature understanding of maturity models. But when I am in the "group think" of conferences (at least a few years ago) it appears that concept gets lost..

Once again, my comment is about the main stream and not the elite..

Brad Vaughan

Still the basics

I get your point, Brad. I would add though that the authors of BS15000 were all involved with the real world - the idea of meeting (basic) requirements across all the disciplines was an honest attempt to get organisations to go beyond basic incident, request and change management.

Whilst I welcome some academic rigour, especially when it comes to setting exams, I do worry about the shift away from the essential basic elements that trip most people up. For instance during a major roll out here today an air conditionning unit has leaked in a server room, taken out the power and short circuited the new comms equipment. The roll out was replacing the comms equipment because it kept failing. The reason it kept failing was because of chronic problems with the air conditionning and power supplies, not the comms kit itself.

A major reason I left one of the big consultancy firms last year was because I was annoyed that clients were being sold foundation certificate holders as "ITIL certified" and the advice they handed out was the advice I would have given when I started out. In other words the advice which looks good when you haven't actually tried it for real such as "start by buiilding a CMDB".

At conferences you get people who are still new to the ITIL world, and they lack the ability to judge how good the advice they are being given is. This makes them easy meat for both vendors and consultants. We owe it to them to make sure the basics stay centre stage. I guess for me that has got lost somewhere.


Ends and means

I think we have flogged the myth of "Implementing ITIL" to death..

I will throw in the shameless blog plug for the article "Implementing ITIL: Stop or you will go blind" ( http://blogs.sun.com/buraddo/entry/implementing_itil_stop_you_will )

The long and the short is that ITIL is not a product or a solution, just a framework for guidance and the degree of adoption is very much linked to the goals you want to achieve. You really want to adoption a continuous improvement process..

one of your points is very valid. Any form of operational improvement needs funding and discipline. If you need to use the word ITIL to get noticed buy the CEO of CIO, then so be it.. (I love that Dilbert cartoon with the panic caused when the CEO is reading a MIS magazine; use it to your advantage. As long as your project understands that "implementation" is impossible. "An ITIL Implementation" can be a good "Ends to a Means" as long as your not drinking the same Kool-aid you are selling to management.

The bit I disgaree with is a generic belief that your "current state" requires some monumental kickstart. If you IT was so far away from delivering what business needed that some big "step-up" is needed, then the situation would be complete kaos (dogs and cats sleeping together and all that). I have yet to go into a company that was in complete kaos (and I do prefer the "Get Smart" spelling). They all do somethings better than others.. I have even walked into a customer who did nothing the "ITIL way" but to be honest, for the size of the company and the market they were in, the recommendations were. Don't change!!!

I prefer my ITIL to be viral.. Run your specific project (the one problem that is really annoying the business), use ITIL as the "desired state" framework and achieve your discrete metric and ROI.. Help desk ticket closure time, service quality improvement, service uptime, time-to-market on projects, etc.. Move on and apply the same problem solving method to the next critical point..

Please don't Assess -> Architect -> Implement -> Manage PLEASE PLEASE PLEASE

Brad Vaughan

Learning from my own mistakes

If you had asked me a few years ago I would have said the only way forward is to implement ITIL as a project. Older sadder and wiser now I know the reason I said it then was that all the successful ITIL activity I'd seen was indeed project based. Since then almost every ITIL project I've seen seems to have floundered at some point. Why? I guess the early adopters that I knew tended to be highly motivated, had an excellent understanding of what they were trying to achieve and were in positions of real influence within their IT organisations.

What goes wrong now when you try and implement ITIL as a project these days is-

- You get a project manager who doesn't understand that this isn't like delivering a piece of code
- The project development team within the organisation use their control of the project to sabatage any changes suggested by the operations team.
- Management don't understand that progress on what is largly a cultural change activity cannot be measured in conventional ways
- the wrong project approach is used. People default to waterfall mode because Microsoft Project and a background in hardware and software projects encourages that, rather than looking at a more contingent approach, or adopting a Theory of Constraints approach.
- People who should be doing SM activity as part of their day job now see it as the responsibility of the project to deliver something to them, rather than contributing to the change
- Once something is started as project it makes killing it as a project easier, by starving it of resource and management commitment
- The political need to declare a project successful means that false claims end up being made for the real amount of benefit being delivered
-People forget that the real benefit has to be delivered after the project ends and SM enters a BAU stage.
- The succesful project manager gets a job in consultancy as soon as the project is finished, leaving everyone else to fail.
- You end up with 2nd and 3rd generation ITIL projects trying to re-do what the 1st generation project did, rather than moving into new areas.

Before I get totally shot down in flames I should add that I believe adopting a project approach is a very important PART of an ITIL implementation approach. For instance I wouldn't implement a SM toolset without strict project discipline, but for me the future lies in a combination of -

- A programme and portfolio approach rather than a monolithic project
- leveraging other projects to dleiver SM benefits ( Foe instance by ensuring SM influences the NFRs for any new project)
- Continual improvement

Rant over.


ITIL is a cultural and structural change

My observation of hundreds of companies is that the single most important reason for failure to achieve the expected results and move an ITIL process forward is managment's substantial underestimation of the persistent leadership necessary to achieve the structural and cultural changes needed to sustain the significant improvements that can be had.

Implmentation of ITIL requires removal of silos, development of trust, restructuring of the organization to eliminate the tremendous duplications that so often exist in IT - all cultural and budgetary changes that are hard for companies to sustain. The changes needed are obvious, the ability to sustain the changes require sustained leadership towards a vision.

Changing the budgetary approach so that "customers" can actually "buy" services - makes a big difference. As long as traditional budgeting methods allow the micromanagement of IT by cost category instead of running the services as a business there will be little room for building the infrastructure needed to run IT as a business within a business. It turns out that good IT Financial Management may be an important key to the changes. If given the opportunity, IT staff will quickly learn to act as entrepreneurs instead of technologists with a limited focus.

The power of budgeting and accounting


That need for "persistent leadership" is another reason to avoid the project approach.

There seems to be a presumption in th IT world that the only way to control resources and results is to make something/everything a project. In contrast the manufactoring world understands the importance of using management accounting techniques to measure the cost and value of processes.

I don't think "viral" works

I too prefer an incremental approach, addressing the pain spots. But I don't think "viral" works. I believe people need to understand that we don't do things the way we did any more. Formalising disfunctional process areas works. So does defining the interfaces to other areas and clearly delineating ownership and accountability. So does introducing a standard language and mindset to the organisation. None of those work well virally. Get in with an allocated team of people, fix the broken stuff (yes assess/plan/architect/implement), and start an ongoing process to keep it alive and make it better over time. And if that CSI process is not formally defined and measured with ownership then anything you changed will be gone in 24 months.

utopia is a myth

I think we agree, to a certain extent..

By viral I just mean don't attack the "biggest problem".. Big projects mean big failures... The context of my comment on Assess->Architect etc.. is relating to the whole of ITIL for the whole of an enterprise..

You have to apply implementation process, and rigour to everything you do, and you need to involve all the people that have ownership over the change and all that good stuff..

Just solve a problem that needs solving from a very defined tactical perspective and not a big fluffy dream of utopia..

Viral meaning, that once you solved that problem, then you promote and market the method (using ITIL) and start to incrementally get bigger..

Can I implement ITIL in one department of a company, or one sub-unit of ITIL in a company.. Hell yes!!! Is it the ideal situation.. Hell no!! But I can probably success, and get some supporters, and if I fail, I can probably have another shot with the lessons learned..

Live a breath by the "Quick Win", "the Small Start".. Its a religion :)



Brad Vaughan

maturity 5

We are in violent agreement again :-D

People say:
You can't "do" change without config, or release, or ...
You can't "implement" incident management in just one area or team or ...

What they really mean is "You can't get to maturity 5 in ..." Sure. But you can move existing process up a notch on the maturity scale in one or two process areas in one part of an organisation.

But if it isn't approached with rigour and commitment, it's just dabbling

Syndicate content