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

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…