Skip to main content

The Need for Speed

Trends such as virtualization, cloud computing, and agile development have all prompted the need for leaner, more efficient, and more highly automated ITSM processes. Probably one of the things that is most misunderstood about ITIL is that it is a highly scalable framework. Organizations need to understand that if their processes are bureaucratic, it’s most likely because they have made them that way. So in the spirit of continual improvement, what’s an organization to do… throw out ITIL and start over?

That’s what the DevOps folks would have you think. If you haven’t heard of DevOps, according to Wikipedia the term refers to the emerging understanding of the interdependence of development and operations in meeting a business' goal to produce timely software products and services. DevOps has been referred to as (1) a movement, (2) an approach, and one blogger went so far so refer to it as (3) a “framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups.” Launched by a group of European system administrators, the spirit of DevOps is relatively sound… let’s all understand that in this day and age, technology (and more specifically, software) is and must change – and change FAST – or the business isn’t going to make any money. To move quickly, and yet not so quickly that we wreak havoc of the production environment, the “dev” and “ops” folks have to work together.

Proponents of the DevOps movement talk about things like culture change, unified processes, and unified tools… all concepts that are central to ITIL. So where is the disconnect?

We all know that ITIL understands the interdependence between development and operations and the need to foster cooperation, learning, and coordination. We also know that, at times, it can seem that ITIL does so in a heavy-handed way. Controls imposed by governance and security and sometimes just by management’s need to be in control can all add up to less than efficient processes.

So what’s an organization to do? It’s called continual process improvement. It’s remembering that processes are never “done” and there is always room for improvement. It’s remembering that process maturity and culture change takes time and doesn’t end when the processes have been documented and are being supported with a tool.

Continual process improvement involves continually looking for ways to streamline and integrate processes and automate the associated activities. Here are a few good places to start…

Models - Earlier this month, more than 240 people attended Jayne Groll’s webinar Using Models for Incident, Change, Problem and Request Fulfillment Management. The Q&A session associated with this webinar went on for an hour. Models are a basic concept that may be missed during the initial design of a process. Even organizations with advanced ITIL knowledge may fail to fully utilize this valuable concept.  Models = efficiency, models can easily lead to automation, and models are a much needed helping hand at a time when we’re all being asked to do more with less.

Standard changes - Folks often understand the concept of standard changes but apply that concept only to basic things such as installing desktops and commercial software. Virtualization and agile development are prime candidates for the use of standard changes, as are many of the other activities that IT organizations perform on a daily basis. A good place to start is by initiating a project aimed at increasing the number of standard changes. This could involve first further defining what a standard change is and then a set of specific procedures (models) for putting those changes in production. One client shared that they set up a temporary CAB whose role is was to evaluate and implement standard changes. Once the criteria had been fine-tuned and the most frequently performed standard changes had been formalized, the temporary CAB was disbanded. This enabled them to quickly increase the number of standard changes without impacting the work of the main CAB.

Release and deployment management – This process handles much of the coordination between development and operations and is increasingly becoming a hot topic for organizations. A recent ITPI study concluded, “Change management is often identified as a logical starting point for ITIL implementations. However, release management should be the destination for those organizations wanting to achieve performance gain from standardizing on ITIL change and release practices.” An important aspect of the release management process is the release policy. It is often the release policy that dictates how quickly changes can be made and when. In Service Transition, the release policy is an important component of overall transition planning and support. Today, company’s release policy and release management process and procedures must be scalable and flexible. Are there some changes that require tremendous rigor? Sure. Are there many other changes that can be planned, tested, and deployed more quickly (by using models, templates, and automation)? Absolutely.

ITIL can seem overwhelming, particularly at the Foundation level. It can at times seem impractical to those “dev” and “ops” folks who are struggling to get by. There are tremendous opportunities, however, to demonstrate how scalable and flexible ITIL can be and to show how it can be used to do what we all need to do in this day and age… speed up!

Comments

Popular posts from this blog

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group .   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service than toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service

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 th