ITIL-based IT service management (ITSM) has gained in popularity over the past few years and has become known as the de facto standard for how IT organizations operate. And, because it touches every corner of the organization, ITSM is a tremendously powerful discipline.

Of course, its wide-reaching nature also means that certain “safety” measures are needed to ensure that changes made are not just band-aids waiting to fall off. Once you have decided to adopt ITIL in your organization, it's important stop and ask the following questions so you can avoid common pitfalls:

• What are this organization’s current business attitudes and expectations for IT;
• At what maturity does our IT organization need to be;
• How do I quickly turn theory into practice; and
• What IT services do my business customers really need?

In answering these questions, the following must also be considered:

• Are all of my IT processes optimized for delivering these IT services; and
• Is my IT organization and tools effectively enabling and monitoring the IT processes we utilize to deliver IT services?

Most organizations wisely start with their support processes — Incident, Problem, Change, Configuration and Release Management. Prior to gaining any momentum toward increased maturity, these processes must be developed. To this end, the following “safety” tips are provided:

Process Development

Define your process methodology: A well-defined process model has many layers. Take the time to define all the layers of process that will be developed and apply that model to all processes to ensure consistency.

A well-defined process model includes the following:

Process

The overall activities or elements required to meet the objectives of the process.
Procedures– Detailed steps to follow for each of the process activities. Using Incident Management as an example, a detailed set of procedures would include all of the following steps: logging, classification, assignment, resolution, escalation, and closure.
Work Instructions– Detailed tasks to be performed at the lowest level, such as how to open a ticket. This is where process meets tools.

Organization

Conduct roles/responsibilities workshops: ITIL defines various roles and responsibilities for each process. These roles/responsibilities should be clearly defined as part of your process model so each person has a complete understanding of their role in the process.
Create checks and balances with your roles: Some of the processes do not lend well to being filled by one person. The service support processes have built-in checks and balances and combining these roles tends to create confusion and removes the checks and balances.

Technology

Start by creating a technology roadmap: Identify tools that are built on ITIL best practices. Today, tools are friendlier toward integration, which allows organizations to succeed in creating an integrated tool strategy.

Couple your configuration design with your process development: If you design your configuration in conjunction with your process development, alignment is much likelier and easier.

Incident Management

Make the service desk a single point of contact: One of the most detrimental causes of inconsistent support is customers calling second- and third-level support personnel directly and not logging the incident appropriately. This practice does not allow for enhancing service desk personnel's skill sets and takes away from the ability to assign incidents correctly and take advantage of maintaining a history of incidents.

Log every incident at the service desk: By taking advantage of this best-practice, organizations can start to see trends in order to appropriately align problem management techniques to address recurring incidents.

Simplify incident categories, impacts/priorities and completion codes: Having too many categories for incidents causes the service desk agents to log the incident incorrectly, which prevents consistent assignment.

Additionally, priorities and impacts should be assigned based on unique criteria (i.e., service criticality and outage severity). Well-defined completion codes will also allow for other processes such as problem and change management to sort incidents in a manner that allows for effective analysis.

Use templates for standard service calls: Each recurring service call should have a unique template that enables the service desk to provide consistent support or assignment to the correct support group.

Open and close requests at the service desk: This best practice ensures the incidents are closed in the same manner and customers are informed of the resolution.
The service desk agents should then review each completed incident to determine if the customer is satisfied and the resolution summary is meaningful to the customer and can be used for future incidents.

Do not attempt to perform root-cause analysis before restoring the incident. Too often, organizations focus on the root cause of incidents, increasing the duration of the outage. Personnel involved in managing incidents should focus on service restoration and leave root cause analysis to problem managers.

Problem Management

Schedule regular incident reviews: Create a weekly meeting to review all incidents where the root cause was not removed. Reporting on these types of incidents can be easily accomplished by creating a simple completion code such as, "Resolved, root cause not removed." This enables problem managers to quickly identify the incidents that need to be analyzed on a weekly basis.

Focus on customers, not infrastructure: The tendency here is to focus on the most troublesome infrastructure. However, the goal of effective IT service management is to focus on customers. To this end, problem managers should sort recurring incidents by line of business and address the business unit with the most issues.

Identify actual causes vs. blame: Even though actual cause can sometimes be attributed to human error, the real cause may be due to lack of understanding of the process or training.

Change/Release Management

Use change models: Creating standard change models leads to effective and consistent implementation of changes. Developing the workflow of standard changes ensures they are implemented in the same manner every time.

Adhere to the change process: An urgent or emergency change is one implemented for service restoration. Too often, organizations use an emergency change process just to circumvent the normal process.

Appoint a change manager experienced in ITIL: The critical nature of change management requires a solid understanding of the process and its inter-relationships with all the other processes.

Release management is all about execution: Ensure your change management process is in place in order to provide the inputs to release management, such as: build standards, backout plans, testing plans, etc.

Configuration Management

Couple with change management: In order to keep configuration items up-to-date, update the configuration management database (CMDB) as part of every change. The configuration manager should only make modifications to items in the CMDB when an approved change is in place.

Freeze changes before you populate your CMDB: Prior to populating the CMDB, set a policy to freeze all changes. Once you populate the items into the CMDB, control all future modifications through change management.

Follow a defined process to populate the CMDB: Create a logical process such as, populate all physical infrastructure, create relationships for the physical infrastructure, add commercial off-the-shelf software including relationships, then populate business and custom applications (preferably using industry-standard mapping tools).

The path to adopting ITIL can look daunting and unattainable if viewed as a whole. Using these tips can help you focus your adoption and ensure you do not create an umanageable process. As with all things, quality takes time and is only accomplished with clear goals.