Many of my recent consulting interactions with service organizations and their customers has been making one strong statement:Visibility_Page_Header

Service Portfolio needs to be brought into a larger mainstream role over Service catalogue in service provider scenarios. Or in other words, Service Catalogue might have to have a larger scope than just the ‘live and currently offered services’.

First, let us set the context here:

ITIL® has been clear on one aspect:

  • Service Catalogue is the only part of the service portfolio published to customers (ITIL® Service strategy publication).
  • Also the diagram in figure 2.6 in the same publication indicates Service catalogue as the only portion of the Portfolio that is visible to customer

In a typical IT Service management scenarios (especially in external, retail service scenarios), this is more or less logical and accurate.

However, in today’s world of ‘so-called’ Business-IT integration (which ITIL® has been describing from its 2007 edition onward), will this be sufficient?

Let us look at the two scenarios of service providers:

a) An Internal IT Provider:

In this scenario, the business units are the key customers for the Service provider (internal IT department or a shared service unit). In this case, if only the Service Catalogue is visible and used in interactions with the customers, will that suffice for an effective business-IT integration?

It is quite apparent that a visibility into the Service Pipeline is highly essential to achieve effective levels of business and IT integration. In the internal Service scenario, the pipeline will be largely driven by the business strategy and priorities, and hence it is important for the business to have a visibility into the Service Pipeline of IT in order to understand and fine-tune (if and as required) the IT’s strategy and capabilities to ensure alignment to business.

So it is clear that, in an internal service scenario, the Service Portfolio (selective portions of the same, in some cases, where applicable) need to be visible to the ‘customer’ organization to ensure proper alignment and integration.

 b) An External Service provider:

Recently I happened to have interactions with the external customers of an IT solution/service provider. One of the key challenges that were repeatedly voiced by the key stakeholders in customer organization was:

  • Lack of visibility into the future solutions that the solution/service provider was planning to offer and/or the roadmap for the existing solutions/services in terms of enhancements and features.

Why is this important to the customer organization? (more…)


ITIL® Continual Service Improvement (CSI), especially in 2011 edition has a lot of great concepts with clarity; however there are some others, which could have been enhanced with some more clarity.

In this post, I wish to discuss one such topic in CSI that need some clarity: The role of CSI Manager

To start with, let me quote a couple of statements in ITIL® regarding the role:

  •  In the CSI Principles section, ITIL notes that about the role:

A. CSI Manager is the chief advocate who owns all CSI issues

B. While CSI Manager is accountable and responsible for CSI, the CSI Manager is not accountable for improvement to specific Service. Specific Service improvements are responsibility of the appropriate Service Owner working with the CSI framework.

  • Further in the Organizing for CSI section, in the details of the CSI Manager Role, the following points are included:

a) CSI manager is ultimately responsible for the success of all CSI activities.

b) This single point accountability coupled with competence and authority improves the chances of a successful improvement program.

Here are the questions/confusions which I would love get some clarifications: (more…)

Just finished a great training session on Service Strategy over the weekend – great in terms of some insightful discussions with some senior IT folks who attended the training. Some of the discussions were essentially clarifying some very basic concepts, at the same time called for in-depth debates taking scenarios to establish a concrete understanding of those. Thought of blogging the essence of some of those discussions.

One of the area that called for lengthy discussions were on the ‘Service Assets’ and ‘Customer Assets’:

To set the context for Starters: ITIL® (especially the Service Strategy) views a ‘Service’ in terms of Business outcomes facilitated. Basically, these Business outcomes are delivered by the Customer Assets (Customer’s  Resources and Capabilities – people, processes, information, business services etc etc).

What does the IT Service do? They enhance the performance of those Customer Assets to deliver better, or increased business outcomes (and hence delivers business value).

How does the IT service provider deliver these Services? It is by effective use of Service assets (Their resources and capabilities).

So in this context:

  • Service Assets are the Resources and Capabilities of the Service Provider (Service Provider’s Assets) that are utilized to deliver the IT Services to the Business/Customer.
  • Customer Assets are the Resources and Capabilities of the Customer (Customer’s Assets) that are utilized to deliver business outcomes. These assets make use of the IT Services to enhance their performance or to remove some constraints.
  • The Service Provider has to define a Service always in connection to the specific Customer Assets to which the Utility of the service is delivered to (ITIL describes this as the Service Archetype-Customer Asset combination).

So every Service has been defined, planned, designed and delivered with specific Customer Assets in mind. So far so good.

One of the discussion started with some very basic question:

  • Are ‘Users’ and ‘Customer assets’ the same? Or in other words, are Users always the Customer Assets that we talk about in IT Service Definition?
  • If not, how do we differentiate users from the Customer Assets that we are talking about?

The question arised from the basic understanding that ITSM and ITIL used to establish so far: Services are used by Users (and paid for by the customer).

Some of the salient points that were derived from the discussion were: (more…)

Release management (the current Release & Deployment management in ITIL®) process is (as it should be) covering all releases those are deployed into the IT Service environment.

Traditionally in the IT domain, the ‘release’ term is more associated with software than hardware or any other assets. However in ITIL®’s approach to ITSM, the release always been ‘a collection of authorized changes’. These authorized changes can be software, hardware, their combination (service, servers, and infrastructure), configuration changes etc.

Having said this, though ITIL® principally goes with an all-encompassing definition of the word ‘Release’, the documentation of Release & Deployment Management often seem to slip into a (probably unintentional) bias towards Software.  Such an inconsistency can lead to some significant misinterpretation of the best-practice, and the focus of release management can get confined into software alone.

Let us look at how ITIL® (specifically referring to the 2011 edition)  introduces the Release and deployment management process:

The Scope of Release includes: ‘Physical assets such as servers, network, virtual assets, Applications and software, Trainings, Services including agreements and contracts’

However, the stated objectives of Release and Deployment contain statements like:

“…and that all release packages are stored in DML and recorded accurately in CMS”

“Deploy release packages from DML to live environment…”

DML is for software media components. So where are release packages containing Hardware stored?  In DML itself?  Such an interpretation unfortunately doesn’t fit with the definition and explanation of DML – where in, the references are only include Software and media components. (These references to DML are more prominent in 2011 edition, though was there for v3 as well).

Can Definitive Spares (DS) be the area where the Hardware components are controlled prior to deployment to the production environment?  One tends to think it could be. But that is no where referred.

Coming back to the central point of this post, to create a right interpretation of the scope of ‘Release’, it is important that the following one of the following points are taken care of – either in the ITIL® documentation, or by the practitioners during the interpretation of the same:

·         The Scope of Definitive Media Library (DML) should be extended to include ALL release packages. Unfortunately in such a case it will cease to be just a ‘Media Library’. Definitive Release Library (DLR) anyone?


·         Keep the scope of DML as is; but set aside/define definitive storage areas for storing and controlling release packages that contain non-software and non-media components (such as hardware) and refer to them from the release management process- the same way DML is referred from release management.

Till this is taken care of effectively, release and deployment management process scope can get constrained to only Software – which would be unfortunate and ineffective.

Any thoughts/ different view points out there on these are welcome…

ITIL® , the best practice framework for IT Service management-  by the time it has evolved into its third version or as it is called now into the 2007 edition –  came up with a comprehensive definition of “Service” (the same is retained in its 2011 edition as well):

“Means of delivering value to the customer by facilitating the outcomes customer want to achieve, without the ownership of specific costs and risks”

However, it seems to be still unclear (or missing the opportunity) in defining ‘IT service’ and  ‘IT Service Provider’ clearly.  As per the 2011 edition, the definitions are:

“IT service:  Services delivered by an IT Service Provider”

 “IT Service Provider: A service provider providing IT Services to internal or external customers”

Talk about Circular references!

 Can’t we have some better definition or at least better insights into understanding what an ‘IT Service’ is?

No, I don’t have a well thought out definition of ‘IT Service’ on offer here; not yet. However here are some thoughts that might lead us to defining ‘IT service’ better:

What is Information Technology (IT)?

Technology used to:  Process information, Store Information, Transfer information, or Present (visualize, for example) business information.

So the ‘outcome’ expected by customer or business from “IT” (as a provider of service) can be described through:

  • Process, Store, Transfer or Present business information as required by the business
  • While ensuring key aspects like Reliability, Security and Cost-effectiveness

Any systems/technology and/or activity which facilitate the above outcome described above,

  • Without the need of  business/customer to own, manage or worry about the specific risks and  costs of the underlying technology, assets, activities etc.

can be an “IT Service”.

With this context , one possible perspective of looking at IT Service can be as below: (more…)

Rob England (ITSkeptic) said in one of his tweets:

“Back in 80’s , the highest bandwidth channel for data transfer over a range of <5 miles  was a boy on a bike with a basket full of tapes.”

A few minutes later, he also pointed to an article – which is “interesting” to say the least!:

A company in South Africa has done a drill to prove they could use pigeons to tranfer data faster than their telecom provider, Telkom!  Read the story here.

Well, not as a universal truth, but under some context – “* conditions apply!” 😉

The article says internet bandwidth is a growing problem in South Africa.

In the drill/experiment/demonstration/drill or what ever you want to call it, an IT company used an 11 month old pigeon to transfer data disc tied to its legs. The pigeon transferred the data across 80 Km (around 50 miles) in 1 hour and eight minutes; including the data download, the tranfer took a little over two hours – which, reportedly was the time taken to transfer around 4% of data over the telkom’s link!

Okay- enough of fun there . The points to ponder from the story, are these: