Thursday, March 5, 2009

Developing Actionable ITIL Processes

March 5, 2009 By Mike Tainter and Kristy Smith

A sound framework coupled with cultural transformation and results tracking are essential for successfully implementing ITIL, write ITSMWatch columnists Micheal Tainter and Kristy Smith of Forsythe.

Effective adoption of ITIL requires not only the application of ITIL best practices, but also a sound process development framework. Coupled with a campaign of cultural transformation and consistent measurement and results tracking, solid process development techniques will yield repeatable, integrated and actionable processes for managing services and operations across the IT organization.

The Pitfalls of Haphazardness

Haphazard processes can perpetuate inefficiencies, if not chaos, in an IT organization. For example, the complete set of knowledge of an IT organization's activities is usually spread among its many employees. This applies to process documentation, which is too often located in disparate repositories—such as hard drives, shared drives, email folders and people's memories—and is typically stored in many formats such as Word, Visio, PowerPoint, or not documented at all.

Thus, critical process intelligence can be lost or get out of sync when staff members leave, or when the organization grows, restructures or merges. The result is haphazard process development. Haphazard processes may have no clear entry or exit point, too much (or too little) detail, crossing lines, wordy or ambiguous procedure names, undefined roles and ownership, and a lack of clearly defined inputs and outputs to and from other processes.

Figure 1. Haphazard process development

A Sound Framework

A sound process development framework to support development of actionable ITIL v3 processes brings many benefits: centralized knowledge capture, repeatable results, reduced defects, increased collaboration, and a shared process language across the organization. It facilitates continual process improvement, and provides a consistent baseline for measurements, results tracking, and change control.

A good process development framework comprises an online tool built around a multi-layered process model. As depicted in Figure 2, each layer of the model parses the process into progressively lower levels of detail, leading the end user in an intuitive fashion to the specific actions required for thorough ITIL process implementation.

Figure 2. Multi-layered process framework

The four layers of the process framework are: process, procedures, steps, and work instructions and tool tips. Processes, procedures, steps and work instructions are housed within the online tool. The highest and lowest layers, policies and work flows physically reside outside of the online tool, but are still an integral part of an actionable process model. Each layer of an actionable process model is described in detail below.

Policies - A policy is a high-level overall plan that covers general objectives and expectations. For example, a common policy for Incident Management is to use the service desk as a single point of contact for all incidents, while common policies for change management are to establish a change advisory board (CAB) and to define rules for executing different types of changes such as emergency, standard, normal, etc.

Policy development is a responsibility and activity of management. It occurs outside of the process framework, and provides the goal posts toward which all process development is aimed.

Processes - Processes are high-level activities required to meet the policies and objectives of the organization during various phases of the IT service management lifecycle. The major activities for each process can be derived from the various books in the ITIL v3 service lifecycle. This is where it all starts and where ITIL paves the way.

Procedures - Each process should also outline the procedures that establish the set of steps required to complete the process activities. For example, the Incident Management process would have a set of procedures to identify and log; categorize and prioritize; investigate and diagnose; resolve and recover; monitor, track and communicate; and close the incident. Procedures are repeatable and static regardless of the particular incident or change request involved. A procedure is an action—its name always begins with a verb. Every procedure is triggered by a specific event or input, and results in a specific output.

Steps - Each procedure comprises a set of steps, arranged in flowchart fashion, that are followed to complete the procedure. For example, Incident Management contains a procedure to categorize and prioritize the incident. To complete this procedure, you would complete the following steps: determine the request type, record the incident details, identify the impacted configuration item, and determine the priority of the incident.

Work Instructions - Each step contains work instructions which document repeatable, role-based instructions for completing the step. Work instructions are where the processes and procedures meet the IT service management tool; as they explain how to utilize the tool to execute the step, when applicable.

To continue our example above, the work instruction for the step determine the priority of the incident would contain specific information about impact and urgency levels and criteria, and would describe how to indicate the incident's priority within the tool.

Work Flows - The lowest level of detail is the work flow. Work flows are repeatable, role-based instructions for executing a change, fixing a problem or producing a work product. Work flows are dynamic, consisting of the details tailored for each task that IT performs for the business. Documented work flows often reside in the IT service management tool in a pre-populated model or template, and are also referred to as standard operating procedures (SOP).

An example of a work flow is an incident resolution template, an automated service desk template that pre-populates an incident record with appropriate instructions for resolving a recurring incident. Other examples of work flows are standard change; a prescribed set of instructions for building, testing and implementing a repeatable change such as a password reset or a new employee setup; and a test script, a specific test scenario for confirming automated functionality.

Fostering Actionable Processes

Ensuring that ITIL processes are actionable is a challenge that goes beyond process development and documentation. The organization must recognize that a cultural transformation is required to foster acceptance of ITIL and to anchor new behaviors. In addition, a measurement strategy must be employed to track results of the ITIL implementation, to determine levels of adoption, and to promote continual improvement.

An ITIL initiative, like any change initiative, can potentially fall victim to the "dead salmon" syndrome: salmon swim upstream against the flow, lay their eggs and, ultimately, end up dead in the water. An ITIL initiative that is constantly swimming upstream against the cultural flow will likely meet a similar fate.

In his book Leading Change, John Kotter discusses an "eight stage process of creating major change" to effectively lead an organization through cultural transformation. The eight stages are:

  1. Establishing a sense of urgency
  2. Creating the guiding coalition

  3. Developing a vision and strategy

  4. Communicating the change vision

  5. Empowering broad-based action

  6. Generating short-term wins

  7. Consolidating gains and producing more change

  8. Anchoring new approaches in the culture

According to Kotter, stages 1 through 4 of the transformation process help break the status quo. Stages 5 to 7 introduce new practices. And stage 8 grounds the changes in the culture to help them stick.

The pressure to produce quick results often leads to a desire to skip stages or to execute them out of order. Don't be a dead salmon. It is important that all eight stages are followed sequentially. To curtail the desire of individuals to work against the impending change, and to actually nurture enthusiastic support, follow best practices for creating successful change before going down the road of ITIL implementation. Establish a steering committee, form a good foundation of management support, and communicate the vision before proceeding to introduce process and procedural change to the organization.

Change Through Measurement

An essential part of any ITIL implementation is to monitor technical and business results—such as process performance, quality, customer satisfaction, and levels of compliance—utilizing rationalized metrics, reports and auditing. Determine and baseline a set of critical success factors (CSF) with supporting key performance indicators (KPI) and operating metrics (OM). Determine a reporting strategy and schedule. These will be utilized by the steering committee, process owners and managers to measure process conformance, quality and performance.

Keep in mind that it is not reasonable to expect that process will be followed without proper inspection for conformance and performance. You can't expect what you don’t inspect.

Just as important is to measure cultural adoption of ITIL by surveying and interviewing IT staff to learn their attitudes. Are they realizing practical benefits as a result of the ITIL initiative, and does it seem worth the effort so far? Do they have an idea to contribute, or do they want clarification of an issue? This is crucial to making processes actionable and to ensure continual process improvement.

Mike Tainter, Forsythe’s ITSM practice director, has been managing technology and large-scale IT projects for more than 20 years, including IT service management, ITIL,operations management, process design, IT operations support system development, and IT logistical requirements. Tainter holds the Foundation Certificate in IT Service Management and the Manager's Certificate in IT Service Management.

Kristy Smith, ITSM associate consultant at Forsythe, has an extensive background in accounting as well as more than 10 years of IT experience including experience managing IT service management and ITIL implementations and developing ITSM methodologies. Smith holds the Foundation Certificate in IT Service Management.

No comments:

Post a Comment