ITIL Terminology, Part 2

In the first part of this series on ITIL terminology, I examined some of the more commonly used ITIL terms, and discussed the important role terminology plays in understanding ITIL concepts. This second installment focuses on the terminology used to describe specific processes.

In the V3 update of 2007, some ITIL processes were redefined and a few new ones were introduced in an effort to clarify this IT service management framework.

In ITIL V2, a few practitioners focused on just the first 2 books, Service Delivery and Service Support, often ignoring the other 6 books. This was evident during a recent ITIL presentation. When asked how many books were in V2, one attendee confidently shouted "Two!" Her response illustrated the confusion caused by the process-focused V2 structure.

V3 objectives include reducing the ambiguity contained in the previous version, and improving the understanding of the relationship between the processes.

Undoubtedly, the most significant change in ITIL V3 was the introduction of the multiple-phase lifecycle structure. This new lifecycle structure encompasses all the ITIL processes in 5 books, one for each lifecycle phase. The lifecycle organization also adds cohesiveness to the library, making it difficult to focus on just a few books, a common practice with V2 (see sidebar).

Change Management

Although there were no significant changes to this process in V3, some new terms were introduced that affect change management. For example, the Forward Schedule of Changes (FSC) that lists upcoming changes is now referred to as the Change Schedule in V3.

There are many terms used within the change management process. Although not a definitive list of change management terms, the most common terms are defined below:

1. Change — While this might seem a bit obvious, the specific ITIL definition of a change is the addition, modification or removal of a configuration item (CI).
   
   
2. Request For Change (RFC) — A formal request to change one or more CIs.
   
   
3. Normal Change — A type of change that follows the complete change management process. Normal changes are reviewed and approved by the Change Advisory Board (CAB).
   
   
4. Standard Change — A pre-approved, low risk, routine, well-defined and repeatable change to a service or the infrastructure. A standard change is typically processed as a service request through the Request Fulfillment process and does not necessarily follow the complete change management process. Standard changes are approved by a specific delegated authority rather than by the Change Advisory Board (CAB). An example of a standard change is on-boarding a new employee.
   
   
5. Emergency Change — A change that must be completed immediately to repair a service failure that has caused a significant negative impact on the business. Emergency requests are approved by the Emergency Change Advisory Board (ECAB).
   
   
6. Change Advisory Board (CAB) — A committee that meets regularly to assess, approve or reject, prioritize and schedule normal changes.
   
   
7. Emergency Change Advisory Board (ECAB) — A smaller group or subset of CAB members responsible for expediting high-impact emergency requests. The ECAB meets as required.
   
   
8. Change Manager — The person responsible for ensuring all change requests are documented and authorized, and that the Change Management process is performed correctly. The Change Manager usually chairs or participates in the Change Advisory Board (CAB).
   
   
9. Change Schedule — Previously called the Forward Schedule of Changes or FSC, this schedule details all upcoming approved changes.
   
   
10. Projected Service Outage (PSO) — A document that explains the effects of changes or maintenance on service levels, and is an adjunct to the Change Schedule.
    
    
11. Post-Implementation Review (PIR) — A procedure conducted to evaluate the success of a change and identify opportunities for improvement.
    
    
12. Seven Rs of Change Management — A list of questions that help with the change request assessment activity. To analyze the impact a change will have on the business, ask the following:
    
1. Who RAISED the Change?
   
2. What is the REASON for the change?
   
3. What RETURN will the change deliver?
   
4. What RISKS are there if we do or do not carry out the change?
   
5. What RESOURCES will be required to perform this change?
   
6. Who is RESPONSIBLE for this change being performed?
7. What RELATIONSHIPS are there between this and other changes?
   

Service Asset and Configuration Management

This process manages the service assets and configuration items (CIs) that support the other service management processes. Service Asset and Configuration Management (SACM) processes are essentially the same in V3 as they were in V2. However, V3 clarifies the configuration management process and introduces the Configuration Management System (CMS) logical model.

A few of the more significant SACM terms are:

1. Configuration Item (CI) — An asset, service component, or other item that is controlled by configuration management. CIs are classified by category and type with identifying attributes and defined relationships to other CIs. Examples include equipment (printer, server, etc.), specific software versions, documents (contract, procedure, license), and resources (supplier, customer, staff member, business unit).
   
   
2. Configuration Management Database (CMDB) — A physical database that stores the CIs configuration records. One or more CMDBs can comprise the Configuration Management System.
   
   
3. Configuration Management System (CMS) — A logical model of the IT infrastructure comprised of one or more federated CMDBs as physical sub-systems. The CMS stores information on all CIs under the control of configuration management.
   
   
4. Configuration Manager — The person responsible for maintaining information on the CIs required to deliver IT services. The Configuration Manager maintains the CMS logical model containing the IT infrastructure components and their relationships.
   
   
5. Definitive Media Library (DML) — A single logical secure store of the definitive, approved versions of all media CIs. The DML can be comprised of one or more physical locations or libraries containing media CIs such as software versions and electronic documents of a known type and status.
   
   
6. Configuration Audit — A report showing the results of a CMS audit that highlights discrepancies between the authorized CMS records (baseline) and the actual installed CIs. A configuration audit reveals unauthorized changes made to CIs under control of the CMS, and should be performed regularly. Asset discovery tools can be used to create a historical record of the configuration state as of a specific point in time for comparison against the configuration baseline.
   

Conclusions

Understanding the ITIL terminology is an essential first step for determining how to best apply this framework of service management practices. And, V3 presents an improved model that clarifies the ITIL concepts upon which you can develop effective service management processes for your organization.

---

References:

1. Bon, J. van (chief editor) 2007. IT Service Management Based on ITIL V3. Zaltbommel: Van Haren Publishing for itSMF. ISBN 978-90-8753-102-7.
   
2. Office of Government Commerce (Lacy, Shirley and Macfarlane, Ivor). Service Transition, ITIL Version 3. Renouf Pub Co Ltd. ISBN 978-0-11-331048-7.
   
3. Wikipedia, The Free Encyclopedia (28 March 2009). "Information Technology Infrastructure Library" [http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library] (HTML). Retrieved 30 March 2009.
   

By Harry Hiles, HBH Technology LLC — 31 Mar 2009

---

ITIL Terminology

In a previous article, I wrote about the complexity of ITIL, especially with the advent of V3. Without a doubt ITIL is indeed very complex, and this complexity might be the cause of some confusion and misconceptions about the terminology used with ITIL.

In this article, I'll point out some of the more egregious examples of ITIL terminology misuse and provide definitions for some common ITIL terms. Lastly, I'll list the names of the ITIL V3 processes and functions.

An example I see most often is referring to installing or implementing ITIL like you would a software program. Since ITIL only describes good practices and outcomes for IT service management, it might be more accurate to use the terms adopt or apply. ITIL is generally not prescriptive and contains no prebuilt executable processes.

Also, ITIL is not a standard. So it's inaccurate to say products, services, organizations or even people comply with ITIL (again, adopt or apply is more accurate). However, people can be ITIL certified by passing exams given by accredited organizations such as EXIN. Products, services and organizations can't be ITIL certified, but organizations can be certified compliant with the ISO/IEC 20000 international standard for IT service management, which is based on ITIL.

The above examples might seem somewhat trivial. However, inaccurate terms tend to distort ITIL concepts. Even if the writer understands ITIL when they use these terms, it might mislead the reader into thinking ITIL is something it's not.

When ITIL V3 was published nearly two years ago, the library was restructured from process-oriented to lifecycle-oriented. A few processes were redefined and some were added, and the terminology was expanded. Although the restructuring ostensibly clarified the overall framework and better defined the relationships and inter-dependencies between ITIL's various components, it also made ITIL seem more complex.

V3 Books & Terms

To address some of the misconceptions surrounding ITIL terminology, I've complied a list of ITIL V3 terms and concepts gleaned from the V3 authors and other authoritative sources.

Here are the top ITIL terms and concepts:

1. ITIL V3 Books — The 5 core books, one for each lifecycle phase, are:
   
   • Service Strategy
   • Service Design
   • Service Transition
   • Service Operation
   • Continual Service Improvement
     


2. Service — "A means of delivering value to customers by facilitating outcomes the customers want to achieve without the ownership of specific costs or risks."
   


3. Value — "From the customer's perspective, value consists of...utility [what the customer receives] and warranty [how it is provided]."
   


4. Utility — "Fitness for purpose...functionality offered by a product or service to meet a particular need."
   
   
5. Warranty — "Fitness for use...a promise or guarantee that a product or service will meet its agreed requirements [availability, capacity, continuity, information security]."
   


6. Process — "A structured set of activities designed to accomplish a defined objective...processes are measurable, provide results to customers or stakeholders, are continual and iterative and are always originating from a certain event."
   
   
7. Function — "A team or group of people and the tools they use to carry out some or more processes or activities, specialized in fulfilling a specified type of work, and responsible for specific end results."
   
   
8. Procedure — As a component of a process, "a procedure is a specified way to carry out an activity or a process....describes the 'how' and can also describe the 'who' executes the activities."
   
   
9. Work Instructions — As a component of a process, "defines how one or more activities in a procedure should be executed in detail, using technology or other resources."
   

V3 Processes & Functions

Last but not least, here is a definitive list of the 27 processes and functions in ITIL V3 organized by lifecycle phase.

Service Strategy

1. Financial Management
2. Service Portfolio Management
3. Demand Management

Service Design

4. Service Catalog Management
5. Service Level Management
6. Capacity Management
7. Availability Management
8. IT Service Continuity Management
9. Information Security Management
10. Supplier Management

Service Transition

11. Transition Planning and Support
12. Change Management
13. Service Asset and Configuration Management
14. Release and Deployment Management
15. Service Validation and Testing
16. Evaluation
17. Knowledge Management
    
    Service Operation
    
18. Event Management
19. Incident Management
20. Request Fulfillment
21. Problem Management
22. Access Management
23. Monitoring and Control
    
24. IT Operations
25. Service Desk (function)
    
    Continual Service Improvement
    
26. The 7-step Improvement Process
27. Service Reporting
    

In future articles, I'll focus in on the terminology used with specific ITIL processes. Hopefully, with a common vocabulary, we will improve our ability to understand and apply ITIL to our IT service management processes.

---

References:
Bon, J. van (chief editor) 2007. IT Service Management Based on ITIL V3. Zaltbommel: Van Haren Publishing for itSMF. ISBN 978-90-8753-102-7.

By Harry Hiles, HBH Technology LLC — 7 Mar 2009

---

SWOT Analysis

There are several tools available that can help with strategic planning in the early stage of a project. During the planning stage you identify, organize and evaluate information on your current state. One of the most useful tools for organizing information is the SWOT analysis.

The SWOT analysis can help you evaluate your organization's current capabilities and conditions, and is essential for converting this information into knowledge. You can then use this knowledge to effectively define objectives and identify risks.

What is SWOT?

SWOT is an acronym for strengths, weaknesses, opportunities, and threats. The following diagram illustrates how the SWOT analysis defines these four factors.

Each factor is defined as either internal or external (row), and either helpful or harmful (column). The definitions of these four factors are:

• Strengths – These are the internal attributes of the organization that can help achieve your objectives. It defines what the organization does well (its core competencies) and how these strengths can be leveraged.
  
  
• Weaknesses – These are the internal attributes of the organization that can impede progression of the plan and prevent achieving your objectives. It identifies problem areas within the organization and defines the processes it struggles with the most. These weaknesses can be mitigated by bringing in specific skill sets from external sources.
  
  
• Opportunities – These are outside conditions that can help you achieve your objectives. Opportunities can include partnerships with other organizations and acquiring needed skill sets from outside sources and consultants.
  
  
• Threats – These are the outside conditions that might impede your ability to achieve your objectives. Threats can include any external factors that the organization does not directly control. For example, poor economic conditions can be viewed as a threat to achieving your objectives.
  

These SWOT factors can help you plan your objectives. It is usually good practice to first define your future state goals (or vision statement) before attempting a SWOT analysis on your current state.

Then, consider your future state objectives when identifying your SWOT factors. A specific SWOT factor is relevant only within the context of a specific objective. For example, a strength for one objective might be a weakness for another objective.

SWOT Analysis Matrix

The following sample matrix can be used to document the strengths, weaknesses, opportunities and threats of your current state. Identify each factor and list it in the appropriate column (replacing the sample text).

Defining the factors is more effective if performed by a team rather than an individual. Although SWOT is a subjective self-assessment, it is extremely important to be as objective as possible and invest considerable effort when defining your SWOT factors. However, you should avoid becoming bogged down by collecting vast amounts of information and compiling extensive lists of factors.

As previously mentioned, you should identify SWOT factors in relationship to the desired outcomes of your vision statement. This will help you decide which factors are pertinent to your future state goals for the specific project.

Also consider the degree of your strengths and weakness versus industry standards to get a realistic view of these factors. You should also consider the size of an opportunity or threat and define its relationship to your strengths and weaknesses.

After listing your organization's strengths, weaknesses, opportunities and threats, the next step is to define your specific objectives using the results of the SWOT analysis. This is accomplished by aligning your future state goals with the results of your current state assessment.

SWOT analysis is a simple tool that is useful in just about any decision-making or strategic development process. Some examples include applying ITIL practices, developing marketing strategies, and proactive crisis management.

As you can see, there are several ways a SWOT analysis can help you achieve your outcomes. For more information on SWOT analysis, see this Wikipedia article.

By Harry Hiles, HBH Technology LLC — 1 Mar 2009

---