Skip to main content

Learning the Language of ITSM

In order to create a successful foundation for our implementations of ITSM and ITIL® we can take lessons from the study of languages. The foundation of the service management best practices is a language that needs to be understood, mastered and used, just like you would learn a foreign or native tongue.

When learning a new language there are two basic approaches one can take. You can study the grammatical theory and structure or you can do immersion learning. Language experts tell us that both are necessary actually to master or become fluent in a language. Immersing yourself in a language (such as ITIL) provides a conversational or daily usage basis. Think of this as having insight as to “how” the language works. Studying the theory and structure of a language (such as ITIL) provides for an understanding and knowledge basis. Think of this as having insight as to “why” the language works. Without theory there would be no usage since you would be unable to form new sentences, only memorize words. Without daily usage the theory remains academic and leads to “dead” languages. By tying the two together we can create a strong foundation.

To truly master ITIL you need to read the best practices, think about them and read them again. Then the readings need to be coupled with education (learning to know) and understood by applying, analyzing, synthesizing and evaluating the guidance contained in best practices. Then further research and study should lead you to explore aspects of the best practices in greater depth to provide a deep understanding of “why” best practices work and how they can be applied in just about any organization.
To be able to use ITIL you need to immerse yourself in the language and terminology. This means using the language at every chance you get. Begin by focusing on the basic terminology—service, service management, incident, problem, change, event, value, utility, warranty, etc. The key is to use the words often and correctly. Refer back to the best practices as needed to ensure that you know and understand the terminology and that you are using it correctly. Then couple your usage with immersive training (learning to do) where you get to practice the language in sample environments and situations.
Each time you recognize a disruption in service quality or delivery use the term “incident” and be sure to avoid terms like “issue”, “event” and especially “problem” since those terms have their own unique definitions and usages. Would you use the term “tree” when referring to a “bush” or “plant”? Although similar, they are different and unique and should be referred to using their unique terms. However, if you recognize a “problem” then by all means use that term to refer to the underlying causes.
Then think about what practices says about “how” to resolve an incident. Follow the guidance in its simplest and most basic forms at first. Do not attempt to create a complex implementation of an incident management or other process based on a full, deep understanding of the best practices if you have not become fluent in the language of ITIL first. This would be the equivalent of trying to write or speak like a native speaker when all you really know are some basic words or phrases from a guidebook.
Take your implementation one step at a time. The first step for ITSM is to learn the language and use it until you become fluent. Then go forward and create the next great ITSM implementation!


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service". I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize: SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle. ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for th