provided by: 
Originally published at Internet.com The No.1 reason for IT Infrastructure Library (ITIL) adoption according to a recent Evergreen Systems report is to improve service quality.
Reports by various industry analysts claim that about 80% of service desk calls result from change-related failures self-inflicted by IT.
Since most service desk calls result from failed changes, the largest impediment to service quality is the IT department itself. IT is its own worst enemy, and is the No.1 preventable cause of IT service outages.
Many consultants advise adopting formal change management (CM) processes as a solution to this common IT organizational problem, explaining why one of the most common starting points for ITIL adoption is change management.
The goal of ITIL CM is "To ensure that standardized methods and procedures are used for efficient and prompt handling of all Changes, in order to minimize the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organization."
While many templates and examples exist to ease implementation of CM, few realize how hard it is to actually achieve the tight control required. In most organizations, staff is lean and formal CM is added work.
This is why most staff within IT dislikes CM-they feel it just gets in the way of what they know they need to do. There is merit in their feelings, as the very first potential problem described in the ITIL is how an over-bureaucratic process can diminish process effectiveness.
An IT organization improves service quality through CM without becoming overly bureaucratic by realizing what few consultants ever mention: that CM has two purposes: 1) limit change-related incidents, and 2) improve the efficiency and effectiveness of day-to-day operations.
The second purpose is what most consultants forget, and the result is often a process rightly perceived by staff as bureaucratic, unrealistic, and useable.
Most realize that slowing down and reviewing change requests results in better planning and implementation that, in turn, reduces failed changes. But the time required for this review and planning is often missing.
To gain more time, the CM system must handle fewer change requests. The trick is to split requests into two broad types: those that need approval (change requests) and those with pre-approval (service requests).
Standard Change
Change requests require centralized approval and formal CM process review and control. Service requests are de-centralized, pushed as far down as possible, and performed by the lowest possible level within the organization.
The secret is the little known standard change. ITIL describes a standard change as " ... a change to the infrastructure that follows an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements."
In other words, the generally accepted response to a service request is a standard change, not a change request.
Implementing a collection of pre-approved standard changes for the most common service requests can improve efficiency and effectiveness of staff, resulting in fewer change requests needing formal CM. It can also make IT staff more content and empowered.
The idea is powerful and simple: allow qualified staff to perform routine changes without going through the CM process.
Such changes require formal documentation and preparation of a procedure for action determination, execution, reporting, and control. The following example helps make clear the purpose and benefits of standard changes.
A user requests installation a new software application. Without any form of CM, IT installs the software without researching any potential issues. Then, after installation, the user starts having issues with a pre-existing application.
Over time, the normal response by IT is to disallow any new software insttallations without a change request and formal CM review. This is the safe bet, and will reduce occurrence of such issues, however, it is very inefficient because the user has to wait longer; IT Staff has to complete and process more paperwork; and CM gets bogged down with many change requests.
A better approach is to treat such an inquiry a service request. The IT staff worker follows a well defined and pre-approved procedure to perform the work. Upon completion of the procedure the worker updates required documentation such as the CMDB, and produces management information.
The following 6 steps outline how to get started with standard changes.
Create a process for authorizing standard changes. Create a formal process for the identification, implementation, and management of standard changes.
* Standard changes require pre-approval by CM but, once approved, they do not require case-by-case change management approval. * Standard changes require regular reporting and audits to make sure that as the organization changes they remain appropriate. * Establish specific groups and authorizations. Only authorized groups under defined situations should perform standard changes. * Identify those changes that make good standard changes.
Identify candidates for standard changes. Identify, document, and institutionalize those tasks that are well known, proven, and done every day.
The following steps help identify standard change candidates:
* Ask workers what activities they think ought to become standard changes. * Review change logs and histories for changes done often. * Consider who is to perform the work. Many standard changes begin at the service desk in response to service requests. * If cost is a factor, seek those changes where budgetary approval lies with requester.
Write standard operating procedure (SOP). A SOP lies at the heart of every standard change. The SOP defines when, where, how, and by whom the standard change occurs.
It includes:
* Defining the scope and timeframe for authorization. * Involving the group approved to perform standard changes in SOP creation to capture their skills and buy-in. * Procedures for failed standard changes. CM or the designated owner of standard change should examine every failure and make changes as required.
Train, test, and release. Train workers on the new SOP.
Put the SOP under CM control. All changes and modifications to the SOP require formal CM review.
Manage, monitor, report, and audit. Review the success of the standard change(s) to make sure they are appropriate.
* Reporting should show no adverse impact and a percent reduction in change request backlog.
Standard Changes empower an organization, involve IT Staff, reduce bureaucracy, improve performance, and cost virtually nothing to implement.
Involving the staff that will execute the standard change incorporates their combined knowledge and helps assure a process that is efficient and most importantly effective.
Instead of feeling chaffed by a bureaucratic process, workers will feel empowered. Allowing staff to make changes they are competent and capable of performing has the added bonus of spreading the work around the organization.
Institutionalizing work that is already getting done in your organization as standard changes can help you achieve the twin goals of CM: limiting change-related incidents and improving the efficiency and effectiveness of day-to-day operations.
You will also have a reduced backlog, a happier staff that is more empowered and committed, and no one will feel that CM is bureaucratic, unrealistic, or useable.
Understanding the proper place of change requests and service requests, and how to organize to support them, is the solution to the No.1 preventable cause of IT service outages!
Hank Marquis is a managing partner and CTO at itSM Solutions . You can contact Hank at hank.marquis@itsmsolutions.com.
Author: Hank Marquis
Read article at Internet.com site