Module 2.2 - ITIL v3 Foundation - more of those TLA's
Written by David Noel-Davies   


ImageWell, it’s another week and another module.  IT Contractors and ITIL are conjoined twins when viewed by potential clients, and although its painfully detailed it has to be for a very good reason, many organizations will only select parts of ITIL that suit their needs, the low hanging fruit if you will, something nice and easy to present as long as it fits and does not make them look bad, and once installed they leave it alone, believing that there part has been played.


Which Is why we have such a meticulous framework to work to.


Here we will disseminate the Lifecycle, and more TLA’s we need to get to grips with, but not before a pop quiz to see if anyone has fallen asleep.



Q) What is a service?

  • <!--[if !supportLists]-->a)     <!--[endif]-->A business benefit facilitated by IT in support of a tactical goal
  • <!--[if !supportLists]-->b)    <!--[endif]-->An intangible output supporting the availability, distribution and manipulation of information
  • <!--[if !supportLists]-->c)     <!--[endif]-->A customer-funded deliverable designed to meet a commercial aspiration
  • <!--[if !supportLists]-->d)    <!--[endif]-->A means of facilitating outcomes desired by customers


Q) What is Service Management?

  • <!--[if !supportLists]-->a)     <!--[endif]-->A set of specialized organizational capabilities providing value to customers in the form of services
  • <!--[if !supportLists]-->b)    <!--[endif]-->A set of books defining best practice techniques for managing services over their lifecycle
  • <!--[if !supportLists]-->c)     <!--[endif]-->A set of resources for managing the IT infrastructure over its lifecycle
  • <!--[if !supportLists]-->d)    <!--[endif]-->A functional model designed to vertically integrate and align IT capabilities


Q)What is the difference between a role and a function?

  • <!--[if !supportLists]-->a)     <!--[endif]-->A role is singular (one person)  while a function is plural (many people)
  • <!--[if !supportLists]-->b)    <!--[endif]-->A function provides the resources and tools needed to execute processes and activities while a role defines responsibilities and authorities
  • <!--[if !supportLists]-->c)     <!--[endif]-->A role can be performed by an individual or team while a function can only be performed by an individual
  • <!--[if !supportLists]-->d)    <!--[endif]-->A function needs to be managed while a role does not.



Service Operation (SO)

The service operation volume embodies practices in the management of service operations. It includes guidance on achieving effectiveness and efficiency in the delivery and support of services so far as to ensure value for the customer and the service provider. Strategic objectives are ultimately realized through service operations, therefore making it a critical capability. Guidance is provided on how to maintain stability in service operations, allowing for changes in design, scale, scope, and service levels. Organizations are provided with detailed process guidelines, methods, and tools, for use in two main control perspectives; reactive and proactive. Managers and practitioners are provided with knowledge allowing them to make better decisions in the areas such as managing the availability of services, controlling demand and, optimizing capacity utilization, scheduling of operations, and fixing problems. Guidance is provided on supporting operations through mew models and architectures such as shared services, utility computing, web services, and mobile commerce.


Service Operations (SO)

To Coordinate and carry out day to day activities and processes to deliver and manage series at agreed levels.


  • Ongoing management of the technology that is used to deliver and support services
  • Where the plans, designs and optimizations are executed and measured


The purpose of Service Operation is to coordinate and carry out the activities and processes required to deliver and manage service at agreed levels to business users and customers. Service Operation is also responsible for the ongoing management of the technology that is used to deliver and support services.


Well designed and implemented processes will be of little value if the day to day operation of those processes is not properly conducted, controlled and managed. Nor will service improvements be possible if day to day activities to monitor performance, assess metrics, and gather data are not symmetrically conducted during Service Operation.




Service Operation include the execution of all ongoing activities required to deliver and support services. The scope of Service Operation includes:



The services themselves. Any activity that forms part of a service is included in Service Operation, whether it is performed by the Service Provider, an external supplier or the user or customer of that service.



Service management processes. The ongoing management and execution of many Service Management processes are performed in Service Operation. Even though a number of ITIL processes (such as Change and Capacity Management) originate at the Service Design or Service Transition stage of the service lifecycle, they are in use continually in Service Operation.



Technology. All services require some form of technology to deliver them. Managing this technology is not a separate issue, but an integral part of the management of the services themselves.



People. Regardless of what services, processes and technology are managed, they are all about people. It is people who drive the demand for the organizations services and products, and it is people who decide how this will be done. Ultimately, it is people who manage the technology, processes and services. Failure to recognize this will result (and have resulted) in the failure of the Service Management projects.



Value to business of Service Optimization (SO)



Where actual value of strategy, design and transition are realized by the customers and users.






Where business dependency usually commences



Each stage in the ITIL Service Lifecycle provides value to the business, For Example, service value is modeled in Service Strategy, the cost of the services is designed, predicted and validated in Service Design and Service Transition, and measures for optimization are identified in Continual Service Improvement. The operation of the service is where these plans, designs and optimizations are executed and measured. For a customer viewpoint, Service Operation is where the actual value is seen.


Achieving Balance (conflict Motives)


Service Operation is more that just a repetitive execution of a standard set of procedures or activities. All functions, processes and activities are designed to deliver a specific and agreed level of services, but they can have to be delivered in an ever changing environment. This forms a conflict between maintaining the status qui and adapting to changes in the business and technological environments, One of Service Operations key roles is therefore to deal with this conflict and to achieve a balance between conflicting sets of priorities. Service Operation highlights some of the key tensions and conflicts, and identifies how IT organizations can recognize that they are suffering from an imbalance by tending more toward one extreme or the other. It also provides some high-level guidelines on how to resolve the conflict, and thus move towards a best practice approach. Every conflict therefore represents an opportunity for growth and improvement.


Internal IT view vs external business view

The most fundamental conflict in all phases of the IT Service Management Lifecycle is between the view of IT as a set of IT Services (external to the business view), and the view of IT as a set of technology components (internal IT view).

The external view of IT is the way in which services are experienced by its users and customers. They do not always understand, nor do they care about, the details of what technology is used to manage those services. All they are concerned with is that the services are delivered as required and agreed.

The internal view of IT is the way in which IT components and systems are managed to deliver the series. Since IT systems are complex and diverse, this often means that the technology is managed by several different teams or departments – each of which is focused on achieving good performance and availability of “their” systems.

Stability vs Responsiveness

No matter how good the functionality is of an IT service and no matter how well it has been designed it will be worth far less if the service components are not available or if they perform inconsistently. This means that Service Operation needs to ensure that the IT infrastructure is stable and available as designed. At the same time Service Operation needs to recognize that the business and IT requirements change.

Some of these changes are evolutionary, for example, the functionality, performance and architecture of a platform may change over a number of years. Each change brings within it an opportunity to proved better levels of services to the business. In evolutionary changes it is possible to plan how to respond to a change an thus maintain stability while responding to the changes.

Quality of Service vs Cost of Service

Service Operation is required to consistently deliver the agreed level of IT service to its customers and users. While at the same time keeping costs and resource utilization at an optimal level.

Reactive vs Proactive

A reactive organization is one which does not act unless it is prompted to do so by an external driver, for example, a new business requirement, an application that has been developed, escalation in complaints made by users and customers. An unfortunate reality in many organizations is the focus on reactive management mistakenly as the sole means to ensure services that are highly consistant and stable, actively discourage proactive behavior from operational staff. The unfortunate irony of this approach is that discouraging effort investment in proactive service management can ultimately increase the effort and cost of reactive activities and further risk stability and consistency in services.

For Example, an IT department that will only take action when the business complains about something will always be seen as an obstacle to progress. On the other hand, if the IT department keeps investing in new technology to fix things that are not broken they will be seen as draining the company’s finances.


The value of communication

Good communication is needed between all ITSM personnel and with users/customers/partners

Issues can often be mitigated or avoided through good communication

All communication should have:

           Intended purpose and/or resultant action

           Clear audience, who should be involved in deciding the need/format


  • Right information
  • Right people
  • Right Time
  • Right format


Good communication is important across all phases of a service lifecycle but particularly so in Service Operation.

Good communication is needed with other IT teams and departments; with users and internal customers and between the Service Operation teams and departments themselves. Issues can often be prevented or mitigates with appropriate communication.

An Important principle is that all communication musts have an intended purpose or a resultant action. Information should not be communicated unless there is a clear audience. In addition, that audience should have been actively involved in determining the need for that communication and what they will do with the information.

Please not that there is no definitive medium for communication within each team or department and for each process. Although this should be formal, the policy should not be cumbersome or complex.




Continual Service Improvement (CSI)

The continual Service Improvement volume provides instrumental guidance in creating and maintaining value for customers through better design, introduction, and operation of services. It combines principles, Practices, and methods from quality management, Change management, and capability management.

Organizations learn to realize incremental and large scale improvements in service quality, operational efficiency, and business continuity. Guidance is provided for linking improvement efforts and outcomes with service strategy, design and transition. A closed loop feedback system, based on the Plan, Do, Check, Act (PDCA) model specified in ISO/IEC 20000, is established and capable of receiving inputs for change from any planning perspective.

Continual Service Improvement (CSI)

Aims to continually align IT services to changing business needs by identifying and implementing improvements.

Continually looking for ways to improve process efficiency and effectiveness as well as cost effectiveness

            Complacency is the single biggest enemy of continual improvement

The Objectives of CSI are to:

            Review, analyze and make recommendations on improvement opportunities in each lifecycle phase: Service Strategy, Service Design, Service Transition, and Service Operations

            Review and analyze service level achievement results

            Identify and implement individual activities to improve IT service quality and improve the efficiency and effectiveness of enabling ITSM processes

Improve costs effectiveness of delivering IT Services without sacrificing customer satisfaction

Ensure applicable quality management methods are used to support continual improvement activities.

Scope of Continual Service Improvement (CSI)

            Overall health of ITSM as a discipline and of the services

            Alignment of the service portfolio with business needs

            Maturity of processes

Value to the Business of Continual Service Improvement (CSI)

            Improve service quality, higher availability

            Gradual cost reductions and better cost-justification

            Better information about existing services and areas for improvement

            Better business / IT alignment

            Increased flexibility and adaptability

            Improved communication

            ROI / VOI

There are four commonly used terms when discussing service improvement outcomes:



            ROI (Return on Investment)

            VOI (Value on Investment)

Much of the angst and confusion surrounding IT Improvement initiatives can be traced to the misuse of these terms, below is the proper use:

            Improvements: Outcomes that when compared to the ‘before’ state, show a measurable increase in a desirable metric or decrease in an undesirable metric.

                        Example: ABC Corp achieved 15% reduction in failed changes through implementation of a formal Change Management process.

            Benefits: The gains achieved through realization of improvements, usually but not always expressed in monetary terms.

                        Example ABC Corp’s 15% reduction in failed changes has saved the company $395000 in productivity and reworks costs in the first year.

            ROI: The difference between the benefit (saving) achieved and the amount expended to achieve that benefit, expressed as a percentage. Logically, one would like to spend a little to save a lot.

                        Example: ABC Corp spent $200,000 to establish a formal Change Management process that saved $395,000. The ROI at the end of the first year of operation was therefore $195,000 or 97.5%

VOI: The extra value created by establishment of benefits that include non-monetary or long term outcomes. ROI is a subcomponent of VOI

                        Example: ABC Corp’s establishment of a formal Change Management process (which reduced the number of failed changes) improved the ability of ABC Corp to respond quickly to changing market conditions and unexpected opportunities resulting in an enhanced market position. In addition, it promoted collaboration between business units and the IT organization and freed up resources to work on other projects that otherwise may not have been completed.


Quick Learning Check:

Which of the following is not within scope of development for Service Design?

<!--[if !supportLists]-->a.     <!--[endif]-->New and changed services

<!--[if !supportLists]-->b.    <!--[endif]-->Technology architecture and management systems

<!--[if !supportLists]-->c.     <!--[endif]-->Measurement methods and metrics

<!--[if !supportLists]-->d.    <!--[endif]-->Release and Deployment planning

When transitioning a new service into a production environment, which of the following activities should be considered?

<!--[if !supportLists]-->a.     <!--[endif]-->Ensure that the proposed changes can be used in accordance with the requirements and constraints

<!--[if !supportLists]-->b.    <!--[endif]-->Define measurement metrics and methods

<!--[if !supportLists]-->c.     <!--[endif]-->Evaluate process maturity and integration

<!--[if !supportLists]-->d.    <!--[endif]-->Maintain the status quo to achieve infrastructure stability