Those of us who have implemented, are implementing, or are planning to implement IT service management often ask about the best way to organize around the ITIL guidance.
The recent refresh of ITIL – Version 3 – has significantly expanded on this particular area.
Those familiar with ITIL’s Version 2 know that these volumes focus on establishing cross-functional processes based on proven industry guidance; and that addressing the ‘white space’ in the organization chart by implementing cross-functional processes is not that easy.
As V3’s Service Strategy states, [Functions are often mistaken for processes.], and perhaps more important [What Are Services?].
It is no accident that virtually every V3 volume contains guidance in these areas, but you need to understand some terms first.
Coming to Terms with V3
Service Management - [Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.]
Organizational capabilities combine processes and functions for managing services over a lifecycle.
Services - [A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.]
Value - [Value consists of two primary elements: Utility or fitness for purpose ….Utility is what the customer gets, and Warranty or fitness for use… warranty is how it is delivered.]
Outcomes - [The result of carrying out an activity, following a process, or delivering an IT service. The term Outcome is used to refer to intended results, as well as to actual results.]
The concept of Outcomes is interesting. To quote V3:
[An outcome-based definition of service moves IT organizations beyond business-IT alignment towards business-IT integration...Requirements are generated for internal control only after customer outcomes are well understood.]
Customer - [Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group that defines and agrees the Service Level Targets…]
This may be the most confusing word of all for many IT organizations. Who is the Customer of services that are ‘internal’? There may be no invoices, SLAs or any other documents that clearly indicate who the Customer is (or should be). Simply discussing these relationships often plants the seeds of organizational change.
[While the organization chart is a useful administrative tool, it is missing key components. It is missing the customers. It is missing the services provided to customers. And it is missing the workflow through which those services are provided.]
Understanding the complexity of Customers and Suppliers, as they relate to Processes and Services is likely to remain a challenge for many.
Organizational Capabilities
[Specialization is a necessary condition for developing organizational capabilities.]
Many organizations have established functional units that aggregate specialized knowledge based on technical domains, but it’s really the lack of coordination that creates those IT silos.
I suppose this is why V2 had a process focus; it centered on improving coordination between functional units by implementing proven support and delivery processes. V3 does not change that!
Functions – [Organizational units specialized to perform certain types of work.] They focus on the specialization principle.
Processes - [A set of coordinated activities in order to produce an outcome (or goal).] They focus on the coordination principle.
It’s important to note that both Processes and Services have Customers!
Resource – [A generic term that includes IT infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an organization.]
Human resources have Roles to play in both Functions and Processes in the various Lifecycle stages of delivering services, and so:
Roles - [A set of responsibilities, activities and authorities granted to a person or team. A Role is defined in a process. One person or team may have multiple Roles…]
From V2 to V3 – The Evolution of Language
We had a bad dose of Kool-Aid in V2, in the form of way too much enthusiasm over the Configuration Management Data Base (CMDB). This resulted in some bad trips; coming out of your Foundation class, putting 90 pounds of air in the tires, and stepping on the accelerator is still not the safest path to enlightenment.
CMDB’s must evolve over time, cannot be bought, and many felt (and still feel) that a true ITIL defined CMDB cannot be done at all. Few would argue however, that one must get a handle on critical dependency data and establish ‘trusted sources’ of information and that takes time.
Configuration Management System (CMS) – [A set of tools and databases that are used to manage an IT Service Provider’s Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, business units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management processes.]
The addition of the term CMS to V2’s CMDB is evidence of an evolution in terminology that brings us much closer to reality. I don’t think V2 ever really intended a big bang for the CMDB anyway, an evolutionary theory seems much more reasonable.
Unfortunately, one of the most common mistakes many folks made when pursuing CMDB nirvana was not defining services first; it is a service that gives perspective and context to the CI relationships defined in the CMDB (now supplemented with a CMS in V3).
This is an area where V3 can help significantly.
V3 describes a
Service Portfolio – [The complete set of Services that are managed by a Service Provider. The Service Portfolio is managed by a Service Provider. The Service Portfolio is used to manage the entire Lifecycle of all Services, and includes three Categories: Service Pipeline (proposed or in Development); Service Catalog (Live or available for Deployment); and Retired Services.]
Service Portfolio Management is defined in Service Strategy (see below). As far as putting 90 pounds of air in the tires and stepping on the accelerator, see the following from V3’s Service Strategy:
[Armed with a conceptual understanding of services, organizations frequently rush to industrialize service outcomes. The impulse is to launch initiatives in organizational change or process redesign…there is an order worth noting. While this order is not absolute, it does serve two purposes. First, it warns against missteps such as performing organizational design before knowing what services to offer, or performing tool selection before optimizing processes. Second, it signals the early need for a Service Portfolio, one of the most vital and yet often missing constructs for driving service strategies and managing service investments.]
Beware the V3 Kool-Aid is potentially just as dangerous as the V2 was:
Service Catalog – [A database or structured document with information about all live IT Services, including those available for Deployment. The Service Catalog is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalog includes information about deliverables, prices, contact points, ordering and request Processes.]
Don't get me wrong, I'm a believer in ITIL and feel everyone needs to get on the Right Road and building a Service Catalog is part of that. However, understand that the Catalog is based on the Service Portfolio and that is defined in Service Strategy; know yourself first...
Evolution & organizational change with V3
The new Good Books provide a wealth of information about organizational theory and change based on proven practice. I have been using the term Stakeholder & Services targeting that (happily) maps quite well to the V3 guidance.
Stakeholder & Services targeting is really about agreeing on a high-level Service Portfolio, and targeting improvement efforts based on need and organizational realities. It establishes a service-oriented approach to implementation.
In fact, V3 provides a process for
Service Portfolio Management (SPM) – [The Process responsible for managing the Service Portfolio. Service Portfolio Management considers Services in terms of the business value that they provide.]
SPM must be driven by steering and can establish an ongoing program for evolving the organization. The Service Portfolio can highlight targets for improvement in several ways.
By looking at Stakeholders (including internal and external Customers) and Services, organizational issues can be targeted for action as part of the improvement program.
[Goal setting and reporting are done in silos…This approach prevents cross-silo issues from being resolved at low levels. Instead, the issues are escalated to functional managers who then address the issues with other functional managers…Cross-functional issues frequently do not get addressed, often falling through the organizational cracks. The opportunity for improving an organization often lies in these organizational cracks: the white space of the organization chart.]
So, lack of cross-functional process maturity will still be a primary focus for many.
However, V3’s new processes – including Service Portfolio Management – as well as the wealth of information on organizational development and new role descriptions can help target the improvement efforts in ways that make sense for YOU.
For example, as services are chartered via SPM (Service Targeting) the stakeholders related to the service targets can be clearly identified and process improvement efforts can be concentrated on those stakeholders (Customers and Suppliers) that are relevant to that service.
Service Targeting also improves critical inputs to core processes, such as clear priority setting and identification of dependency data including Configuration Items, Operational Level Agreements and relevant Contracts.
Service Targeting also clearly establishes resources directly from Steering/management, ensuring that proper support is given to the initiative(s).
The gradual development of a robust Service Portfolio and Catalog enables the organization to evolve as well:
[The process for major organizational change involves many events and can be a matter of years rather than months…A service strategy then becomes an implicit blueprint for an organization’s design…The term evolution describes the quieter periods while the term revolution describes the upheaval of management practices.]
Through a constant cycle of ongoing stakeholder and services targeting, business case analysis, and communication organizations can take an evolutionary approach to organizational change. This can keep revolutionary steps to a safe and manageable level. Remember,
Inch by inch, life’s a cinch. Yard by yard, life is hard.
Good luck and drive safely.
