www.itbusinessedge.com

Login Register

www.itbusinessedge.com

 

www.developer.com

Login Register

www.developer.com

 

www.developer.com

Login Register

www.developer.com

 

www.itbusinessedge.com

Login Register

www.itbusinessedge.com

 
Internet.com logo
IT Professionals
Communications

Database

Enterprise Applications

Hardware

IT Management

IT News

Mobile

Networking

Security

Server

Small Business

Storage

ITManagement
CIO Update

Datamation

Earthweb

Enterprise IT Planet

Intranet Journal

IT Career Planet

IT Channel Planet

ITSM Watch

Project Manager Planet

Developers
Architect

Java / OS

Microsoft Technology

Web Development

Sign in Sign in

http://www.itsmwatch.com/itil/article.php/3790896/ITIL-is-Cultural-Not-Technical.htm
Back to Article

By Rob England
Dec 12, 2008

ITIL is a transformation rather than an implementation, i.e. the cultural change of the people is the ultimate objective and the most important part. Don't get fixated on processes or, worse still, technology. Make sure the major spend is on people-change else failure or atrophy is the result.

 

To hear the vendors tell it you might be excused for thinking ITIL is a “skin” of their technology. And to hear many experts and books tell it you might get the impression ITIL is about processes. But it isn’t. ITIL is about changing the way people think and behave; changing “the way things are done around here”; changing what GamingWorks calls ABC: Attitude, Behavior and Culture.

 

In order to drive the change, we improve the processes, or occasionally introduce processes that don’t exist at all. And in order to make the processes more efficient and more effective we sometimes decide to introduce technology. But the underlying objective of the whole exercise is cultural change, transforming the people.

 

Well, that is how it should ideally work. The reality is that sometimes organizations “buy an ITIL”; that is they fall for the vendors’ blandishments and buy a technology “solution” that is expected to give them an “out of the box” ITIL experience. Sometimes they are realistic enough to know the processes will need to change with it, but they expect the new technology to drive that change. Other organizations know it isn’t about the technology. They design and “implement” a whole set of new shiny processes, and then wonder why nobody adopts them and they fall quietly into disuse and disrepair.

 

I was once commissioned to prepare Service Desk, Incident, Problem and Change processes to support a client’s new core IT system. Interviewing a wide range of staff, I found many ad-hoc processes were stumbling along. It was the typical anarchic site: people knew their own piece of the process, but nobody had the whole picture, nothing was documented, nothing much had been planned. It just grew. One day I’m interviewing one of the applications support team at his desk. I spied a chart pasted to the wall behind him and become distracted. It looked like a flowchart of a very detailed incident management process. I looked more closely—it is! I ask if I can have it. “Oh yeah, help yourself. No-one follows that.”

 

It was a bit like an engineer hacking his way through the jungle to make a path, and coming across ruins of asphalt and concrete with a median barrier down the middle!

 

To know what technology you need and how to configure and customize it, you must first know what process improvements are required. To know that, you need the people who operate the processes to engage, to help you with the design. You must start with the people, and the people must be the endgame. The processes and tools are just mechanisms that assist in achieving the end: cultural change—a new ABC.

 

It’s Not New

 

Let’s be clear: ITIL is not about introducing something new. You don’t “do” ITIL, although we are all guilty of using such language. ITIL is not an implementation, it is a transformation. ITIL is about transforming what is already there: transforming the mindset to a customer-centric one by focusing on the services delivered. Usually, we are transforming from a technology-centric mindset where IT exists for the technology’s sake.

 

Another way of looking at this is the maturity of the processes. We are transforming the organization’s “maturity”, from some level to a higher level. The process is already functioning we just make it happen better. Note that maturity is a word used about people. Maturity indicates at what level the people are doing the process, not what level the processes are designed for. Maturity is a measure of culture.

ITIL is a transformation rather than an implementation, i.e. the cultural change of the people is the ultimate objective and the most important part. Don't get fixated on processes or, worse still, technology. Make sure the major spend is on people-change else failure or atrophy is the result.

 

To hear the vendors tell it you might be excused for thinking ITIL is a “skin” of their technology. And to hear many experts and books tell it you might get the impression ITIL is about processes. But it isn’t. ITIL is about changing the way people think and behave; changing “the way things are done around here”; changing what GamingWorks calls ABC: Attitude, Behavior and Culture.

 

In order to drive the change, we improve the processes, or occasionally introduce processes that don’t exist at all. And in order to make the processes more efficient and more effective we sometimes decide to introduce technology. But the underlying objective of the whole exercise is cultural change, transforming the people.

 

Well, that is how it should ideally work. The reality is that sometimes organizations “buy an ITIL”; that is they fall for the vendors’ blandishments and buy a technology “solution” that is expected to give them an “out of the box” ITIL experience. Sometimes they are realistic enough to know the processes will need to change with it, but they expect the new technology to drive that change. Other organizations know it isn’t about the technology. They design and “implement” a whole set of new shiny processes, and then wonder why nobody adopts them and they fall quietly into disuse and disrepair.

 

I was once commissioned to prepare Service Desk, Incident, Problem and Change processes to support a client’s new core IT system. Interviewing a wide range of staff, I found many ad-hoc processes were stumbling along. It was the typical anarchic site: people knew their own piece of the process, but nobody had the whole picture, nothing was documented, nothing much had been planned. It just grew. One day I’m interviewing one of the applications support team at his desk. I spied a chart pasted to the wall behind him and become distracted. It looked like a flowchart of a very detailed incident management process. I looked more closely—it is! I ask if I can have it. “Oh yeah, help yourself. No-one follows that.”

 

It was a bit like an engineer hacking his way through the jungle to make a path, and coming across ruins of asphalt and concrete with a median barrier down the middle!

 

To know what technology you need and how to configure and customize it, you must first know what process improvements are required. To know that, you need the people who operate the processes to engage, to help you with the design. You must start with the people, and the people must be the endgame. The processes and tools are just mechanisms that assist in achieving the end: cultural change—a new ABC.

 

It’s Not New

 

Let’s be clear: ITIL is not about introducing something new. You don’t “do” ITIL, although we are all guilty of using such language. ITIL is not an implementation, it is a transformation. ITIL is about transforming what is already there: transforming the mindset to a customer-centric one by focusing on the services delivered. Usually, we are transforming from a technology-centric mindset where IT exists for the technology’s sake.

 

Another way of looking at this is the maturity of the processes. We are transforming the organization’s “maturity”, from some level to a higher level. The process is already functioning we just make it happen better. Note that maturity is a word used about people. Maturity indicates at what level the people are doing the process, not what level the processes are designed for. Maturity is a measure of culture.


ITIL is a transformation rather than an implementation, i.e. the cultural change of the people is the ultimate objective and the most important part. Don't get fixated on processes or, worse still, technology. Make sure the major spend is on people-change else failure or atrophy is the result.

 

To hear the vendors tell it you might be excused for thinking ITIL is a “skin” of their technology. And to hear many experts and books tell it you might get the impression ITIL is about processes. But it isn’t. ITIL is about changing the way people think and behave; changing “the way things are done around here”; changing what GamingWorks calls ABC: Attitude, Behavior and Culture.

 

In order to drive the change, we improve the processes, or occasionally introduce processes that don’t exist at all. And in order to make the processes more efficient and more effective we sometimes decide to introduce technology. But the underlying objective of the whole exercise is cultural change, transforming the people.

 

Well, that is how it should ideally work. The reality is that sometimes organizations “buy an ITIL”; that is they fall for the vendors’ blandishments and buy a technology “solution” that is expected to give them an “out of the box” ITIL experience. Sometimes they are realistic enough to know the processes will need to change with it, but they expect the new technology to drive that change. Other organizations know it isn’t about the technology. They design and “implement” a whole set of new shiny processes, and then wonder why nobody adopts them and they fall quietly into disuse and disrepair.

 

I was once commissioned to prepare Service Desk, Incident, Problem and Change processes to support a client’s new core IT system. Interviewing a wide range of staff, I found many ad-hoc processes were stumbling along. It was the typical anarchic site: people knew their own piece of the process, but nobody had the whole picture, nothing was documented, nothing much had been planned. It just grew. One day I’m interviewing one of the applications support team at his desk. I spied a chart pasted to the wall behind him and become distracted. It looked like a flowchart of a very detailed incident management process. I looked more closely—it is! I ask if I can have it. “Oh yeah, help yourself. No-one follows that.”

 

It was a bit like an engineer hacking his way through the jungle to make a path, and coming across ruins of asphalt and concrete with a median barrier down the middle!

 

To know what technology you need and how to configure and customize it, you must first know what process improvements are required. To know that, you need the people who operate the processes to engage, to help you with the design. You must start with the people, and the people must be the endgame. The processes and tools are just mechanisms that assist in achieving the end: cultural change—a new ABC.

 

It’s Not New

 

Let’s be clear: ITIL is not about introducing something new. You don’t “do” ITIL, although we are all guilty of using such language. ITIL is not an implementation, it is a transformation. ITIL is about transforming what is already there: transforming the mindset to a customer-centric one by focusing on the services delivered. Usually, we are transforming from a technology-centric mindset where IT exists for the technology’s sake.

 

Another way of looking at this is the maturity of the processes. We are transforming the organization’s “maturity”, from some level to a higher level. The process is already functioning we just make it happen better. Note that maturity is a word used about people. Maturity indicates at what level the people are doing the process, not what level the processes are designed for. Maturity is a measure of culture.


I used to think “cultural change” was an opaque, mysterious term. I thought people who made cultures change would have spooky psychological techniques and arcane political strategies. Well, some might, but the basic principles of cultural change are pretty straightforward. The strategy comes to us from John Kotter with his eight step program, which is readily available by—speaking of cultural change—Googling it.

 

The tactics are nothing special either, but we often do them half-heartedly; as an afterthought to the ITIL project, with minimum budget and even less commitment. Some tactics get ignored. Processes go in with no real training of the users, or zero documentation of what they mean, the work procedures for each specific “actor” (as the UML folk would put it), or no walkthroughs with those actors.

 

So it is not that cultural change is anything exotic. It is just that we often don’t do enough and we don’t do it systematically as part of a cultural transformation program. Once we understand the objective of the project is changing the people, then it should be obvious the bulk of the effort and spending should be directed towards the cultural change activities. These activities include work-shopping, interviews, presentations, newsletters, town halls, walkthroughs, training, go-live, coaching, reviews, monitoring, feedback, and celebration.

 

Grassroots

 

There is no magic to cultural change. Get the people involved, listen to them, empower them, get some enthusiasm going, find some champions, kick it along with executive support, help people out, give them what they need, check all is going well, and pick up the ones who stumble. And have a party when it works.

 

It sounds like hard work, and it can be. But if you don’t it, then some will resist, some will white-ant, some will ignore it, a lonely few will support you, and some will go along reluctantly for a while and then forget or cease to care. Failing to do cultural change is like building something without painting it, or without charging the batteries or fuelling the tank. You can build a fine machine but it won’t go last and it won’t go far. We don’t get proper return on our investment.

 

The typical breakdown of costs for an ITIL project is half technology (and its implementation), a third process re-engineering, and the last little bit on training and rollout. A greater proportion of ITIL projects will succeed long-term when we get to a typical spend of 40% to 50% cultural change, 30%  process reengineering and the rest on tools.

 

Rob England is an IT industry commentator and consultant, and nascent Internet entrepreneur, best known for his blog The IT Skeptic.

 

 

 

 

 

 

 

 


 

Sitemap | Contact Us
Terms of Service | Licensing & Permissions | Privacy Policy
About the Developer.com Network | Advertise
Terms of Service | Licensing & Permissions | Privacy Policy
About the IT Business Edge Network | Advertise
Acceptable Use Policy
Terms of Service | Licensing & Permissions | Privacy Policy
About the Developer.com Network | Advertise
Acceptable Use Policy
Terms of Service | Licensing & Permissions | Privacy Policy
About the IT Business Edge Network | Advertise