Skip to main content

Posts

The Semantics of ITIL and ITSM

In a recent class I heard learners intone that ITIL and ITSM is just an argument over semantics. For those not familiar with the term, "semantics" is the study of the use of specific words in a given context. And yes, ITIL and ITSM are really all about semantics. That is because semantics are important. How and when we use specific words can change the complete meaning and intention of our communication. This is important because the words we use in conversation or written communication reveal our thoughts, beliefs, assumptions, behavioral patterns and wisdom. ITIL in particular is like a language. Different languages approach the idea of semantics differently. A language like English or the Latin- based languages have relatively few words that have multiple meanings and can be used in many different contexts or usages. A language like Greek or some Inuit languages have a lot of words that have very specific meanings and can and should only be used in specific contexts

Balance in Operation III

In every organization the one constant is change.   In service operation, all functions, processes and related activities have been designed to deliver specific level services.   These services deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.   Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation is to deal with the tension between these ever changing priorities. This struggle can be broken down into four general imbalances that provide the service provider an opportunity to develop some guidelines to resolve these conflicts: ·          Internal   IT view vs. External

Conducting an Internal ITSM Asssessment

One of my followers recently asked about approaches to performing an organizational ITSM assessment.   I’ve summarized some of his questions: 1.       While surveys, interviews and workshops are assessment methods, would focused interviews with individuals pertinent to the process being assessed be a good approach?   2.       Should my final assessment score for a process be an average of several people’s maturity level ratings on that process? 3.       Should my assessment only include participants who are directly involved with that process? Assessments should take a well-rounded approach to gathering information, input and feedback.   It’s not a one-size-fits-all.   If you have the ability to conduct one-on-one interviews with key stakeholders, that’s a great way to encourage dialogue through open-ended questions.   While the results may not be as measurable as some other assessment techniques, interviews provide the unique opportunity for deeper probing and fo

VOI and ROI of Release and Deployment Management

I was recently asked about the ROI and VOI of Release and Deployment Management.   Let me start by acknowledging that there is a lot of confusion about the difference between Release and Deployment Management and Change Management.     Change Management is a risk management, governance process.     Release Management is more actionable – it is about bringing one or more changes to life through defined pre and post production activities.    You could almost call it the DevOps process. The growing requirement   for rapid (some would say continuous) deployment does not undermine the need for quality releases.     In fact, a structured approach to rapid deployment is more critical than ever since there is less time to flush out errors.   You can make the process more agile by building release models for different types of releases.   The models can match the rigor associated with building, testing, implementation testing and deployment with the complexity, risk, business n

ITSM Education and Training For Everyone

In 1911, Frederick Winslow Taylor initiated the modern practice of business management. In his work Principles of Scientific Management , Taylor put forth the idea that running and managing a business is a science based on data and proven methods, rather than a series of ad hoc, unguided and uncontrolled actions. Unfortunately, Taylor was a victim of his day and age. He had good intentions in putting forth “scientific management”, but based his ideas on some flawed principles. Taylor stated one these principles in this way: “Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation is that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is un

Best Practice as a Meme

When looking at ITSM best practices we need to look at the culture of our organizations and understand how we would transform our organizations into value-laden delivery mechanisms. A culture is just the "known environment in which we live and work." Cultures are organic constructs--they are grown and guided, not imposed or dictated. Every person, group and organization has its own culture. The culture of an organization is really the aggregation of the individual or group cultures found within the organization. As a result if the culture of an individual, group or organization is not an environment focused on delivering value to customers, then transformation should occur. So how do we go about transforming our cultures? We can look to some of the liberal arts for assistance in this. From the study of sociology we find the concept of "memes".   meme--an idea, behavior, or style that spreads from person to person within a culture . Many of you might

“Meeting” is not a four letter word

At one time or another we have all opened our email, only to find a meeting invite and think (fill in bad word of your choice) Different organizations communicate and collaborate in different ways, depending on the message, decision or topic at hand.   Under certain circumstances, a virtual or physical meeting may be the best vehicle for making a decision or collaborating on a common objective.    While most meetings strive to be well controlled, brief and focused on facilitating a set of actions, this does not always happen. Here are some simple and effective ways to ensure that a meeting is a success: ·         Establish and communicate a clear agenda in advance.   This will allow people to prepare properly and will help the facilitator in preventing his or her meeting from being hijacked by one of the attendees. ·        Most organizations have a governing set of rules for participation in a meeting. No biting, scratching, spitting or name calling is encouraged.   R

Balance in Operation II

Last year I delivered an article on the challenges that IT organizations face in trying to balance opposing goal and objectives especially in light of the fact that in every organization the one constant is change.   The focus of that piece was the tension between the perspective that IT is a set of technology components (Internal IT view) and that IT is a set of services (External business view).    All process and functions in Design, Transition and Operation have been design to meet the changing needs delivered by Strategy and CSI.   Insuring that the resulting services continue to deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation together with design and transition is to deal with this tension between these ever changing priorities. S

The Best of CSI, Part 4

Kotter's Principle - Head to Heart Originally Published on April 5, 2010 The other day I was researching John P. Kotter’s Eight Steps for Transforming your Organization. This approach for organizational change is discussed in Chapter 8 of the Continual Service Improvement (CSI) book. While I was exploring his website: http://www.kotterinternational.com , I came across one of his principles which discusses how to present your vision for strategic change. Communicating the corporate vision for change out to an organization is a critical success factor for the adoption of IT Service Management. I agree with Kotter’s principle that not only do you have to speak to the “Head” but you have to speak to the “Heart”. I am extremely passionate about ITSM and the benefits of CSI. The following quote from his website really spoke to me: “People change because they are shown a truth that influences their feelings, not because they were given endless amounts of logical data. When changing

The Best of CSI, Part 3

Creating a Metrics Program Originally Published on November 30, 2010 Every organization should create a metrics program to ensure that business and process improvement goals are being achieved. We need to have the ability to show that processes achieve results and we must review and schedule process audits. A metrics program describes the measurements needed to achieve business goals. It also identifies how to collect the data and how to use the information to continually improve performance. An effective program focuses on what you should measure to achieve business goals, individual process performance and process interfaces. Each of the best practice frameworks stress metrics as a way of assuring continual improvement. ITIL defines the "7 Step Process" for identifying, collecting, analyzing and using data.  The Deming Cycle's "Check" stage requires that we have methods for monitoring and measuring processes.  The Balanced Scoreboard looks at performa

The Best of CSI, Part 2

Sustainment Originally Published on August 21, 2012 Performance (noun): The capabilities of a person, process or system, esp. when observed under particular conditions How long can you hold your breath? How fast can you run? How long can you go without food and water? Each of these questions is tied to an understanding of your personal ability to perform. The same holds true of processes and systems. Ultimately a person, process or system can only perform to a peak or optimal level for so long. Energy wanes, process steps get skipped and system elements and components wear down or break. So how do we improve our ability to sustain peak performance? The key is to understand how the person, process or system functions, and understand its limitations and “breaking point”. Once we understand the limits and boundaries of peak performance we can implement Continual Service Improvement approaches to help improve the individual performance of a person, process or system within th

The Best of CSI, Part 1

  We conclude our "Best of" blog series with Continual Service Improvement.   CSI and the 7 Step Improvement Process Originally Published on January 24, 2012 I would like to revisit the 7 step improvement process from the perspective of CSI, since there has been a slight (logical) modification to it.   The concept of measurement, what we measure, gathering the data , processing it into understandable formats and then being able to analyze it, is fundamental in our ability to perform (CSI)   Continual Service   Improvement as an overall vision and in support of the business need and the underpinning of tactical and operational goals. 1. Identify the strategy for improvement: (Plan) Talk to the business, to your customers and to IT management.   Utilize your service catalog and the associated service level requirements to define a starting point.   The question “What is important to the business?” must be answered.   Look to the corporate vision, mission, goals

The Best of Service Operation, Part 4

Event Management Activities Originally Published on November 9, 2010 In an earlier blog I was asked how to move from a reactive organization to a proactive one. My answer was through the use of Event Management, along with good design and proactive Problem Management. In this installment I would like to speak to the activities within Event Management and the impact they play in our ability to deliver a consistent level of services and a stable infrastructure to deliver them across. By definition an event is any detectable or discernible occurrence that has significance for the management of the IT infrastructure or the delivery of IT services. Event Management is the process that monitors all events that occur through the IT infrastructure to allow for normal operation and to detect and evaluate the impact any deviation might cause to the IT infrastructure or delivery of IT services. Event Management has several activities that we engage when implementing this process.  Event No

The Best of Service Operation, Part 3

The Value of Known Errors and Workarounds Originally Published on December 7, 2010 The goal of Problem Management is to prevent problems and related incidents, eliminate recurring incidents and minimize the impact of incidents that cannot be prevented. Working with Incident Management and Change Management, Problem Management helps to ensure that service availability and quality are increased. One of the responsibilities of Problem Management is to record and maintain information about problems and their related workarounds and resolutions. Over time, this information is continually used to expedite resolution times, identify permanent solutions and reduce the number of recurring incidents. The resulting benefits are greater availability and less disruption to critical business systems. Although Incident and Problem Management are separate processes, they typically use the same or similar tools.    This allows for similar categorization and impact coding systems.  Each of thes

The Best of Service Operation, Part 2

Tool Selection Criteria Originally Published on February 1, 2011 Service management technology plays a major role in our support of the business. There are enterprise wide tools that support service management systems and processes. There are also tools which support the specific lifecycle phases. You should define your process before selecting a tool. Countless organizations have purchased a tool prematurely, only to find that it does not match the workflow of their newly reengineered process. Defining one or more processes first will help to narrow down the requirements and selection criteria and make it easier for the supplier to demonstrate how their product can complement your new process. Match tools to the process, not the other way around. Wading through all the options, vendors, suppliers can often be a daunting task. Let’s discuss a technique for evaluating tools and finding the product which will support our goals and objectives. What Requirements? Meet with th

The Best of Service Operation, Part 1

We continue our "Best of " blog series by moving into Service Operation.   Cost per Incident Originally Published on August 17, 2010 A reader, upon downloading our ITIL ROI calculator , recently asked the following great question, “how do you determine cost per incident?” Cost per incident is a variation of cost per call or cost per contact, all of which are excellent ways to understand the impact of incidents, calls, or contacts on the business. The calculation is fairly straightforward. Cost per incident is the total cost of operating your support organization divided by the total number of incidents for a given period (typically a month). Cost per incident = total costs/total incidents To accurately calculate cost per incident you must: Log all incidents. You may also find it beneficial to distinguish between incidents (unplanned events) and service requests (planned events). Such a distinction will enable you to more accurately reflect business impact

Handling Incremental Delivery with ITIL Processes

As a follow-up to post regarding the blur between development and service management, a reader commented that DevOps seems to represent a long standing tradition of incremental delivery.   In that case, the reader asks “How is   incremental delivery tracked and managed in an ITIL framework? Would these initial requests for capability tracked as Requests and ultimately as a Request for Change?” As you can imagine, the answer is “it depends”.     An organization can choose to have multiple RFCs submitted or have a single RFC that decomposes into multiple releases but is managed as a single project.   Regardless, the incremental delivery addressed in DevOps is much faster than it was in the past – therefore requiring a tighter integration between development and operations teams – they must communicate well, use shared vocabulary and more importantly, shared metrics and dashboards. Teams that are tightly integrated will have higher rates of rapid change success – so much s

The Best of Service Transition, Part 4

Prioritizing Changes Originally Published in 2011 The Professor recently received the following question: Having put together a spreadsheet of information that I need to assess the impact of a change,  what I need to do next is figure out how to assess the impact of a change as being high, medium, or low? Any guidance you can give me on how to do this would be greatly appreciated.” The  Service Transition book provides great guidance on assessing the impact of changes (ST 4.2.6.4). This section provides 7 questions that must be answered to fully understand the impact. Many of these questions are answered using information in your spreadsheet. Others you may want to consider adding.  Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change?

The Best of Service Transition, Part 3

Early Life Support Originally Published on May 3, 2010 I have found, after doing a number of releases throughout my career, that a solid Early Life Support program (ELS) can really enhance the acceptance and support of any new or changed service. The ITIL Service Transition definition of ELS is the “Support provided for a new or changed IT service for a period of time after it is released." During ELS the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional resources for Incident and Problem Management.   Although stakeholders have agreed to the entry and exit criteria in the Service Design stage, it may become necessary to finalize the performance targets and exit criteria after the build and testing of the service has been completed. This will help to clarify the deployment process and set the proper expectation of the operational resources that will perform the support after ELS has been completed. ELS ensures that ap

The Best of Service Transition, Part 2

Transition Planning and Support Originally Published on February 28, 2012 I am often asked on how to manage transition.   Most organizations find that there are a lot of moving parts.   What happens here effects all stake holders and if expectations aren’t set correctly the reputation of the IT organization can often be at risk and that it can be difficult to meet the changing needs of the business in a cost effective and timely manner.   In order for us to be able to effectively meet these challenges we should start with the big picture process of Transition Planning and Support: The purpose and objective of the transition planning and support process is to provide overall planning for service transitions and to coordinate the resources that are required.   It does that with the following activities: Plan and coordinate resources to deliver the requirements of service strategy that have been translated in service design and insure they are effectively delivered in service oper