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!

Comments

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 policies (r…

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 the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…