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…)

When I attended my initial ITIL® trainings, (it was version 2 at that point) to some of the questions raised by the students (us), the trainer used to (often with a quirky smile) respond ‘It depends!’ – some, with follow-up explanations and others, without.

 I kept hearing the same phrase in answers from many other trainers, consultants, experts, authors and practitioners all along.  I felt some of them using that as a trump card to brush off difficult questions (and quite frankly made a mental note of the same tool for future use!). It is another thing that even the person(s) on the other end also started understanding the trick very soon.

On a serious note, ‘it depends’ is a genuine answer (or prelude to the answer) to many questions regarding ITIL® (or any frameworks similar). Examples:

  • Some “Evergreen” questions in LinkedIn groups and other forums such as: “is password reset an incident or service request”, “ Is Server reboot a change” etc etc…
  • “Which ITIL process should be implemented first? ” or “ which order the processes need to be implemented?”
  • “What categories should Incident tickets have” or “how many levels of priorities a ticket should have”?
  • “What details a Service catalogue should have”

And so on…

It depends…” is not THE answer to the above questions, but it is a good prelude (which sets the perspective right) to the answer, which SHOULD be followed up with a clear explanation on “what it depends on…” and more importantly “why…”. A right combination of these will make the answer the best. (more…)

We can always ask: “What’s in a name?”. But the fact of the matter is most often than not, the name (or title) is of utmost important in setting perceptions and acceptance, when it comes to books, standards and other key documentations at least.

ISO/IEC 20000, the standard has evolved with specific focus on IT Service management.  However, in its 2011 edition of the standard, there seemed to be a clear effort to elevate the standard to a generic Service Management focus – to make it applicable to any Service organizations, IT or non-IT.

A major roadblock in this elevation and global acceptance as a generic standard could be the term that remained in its title: “Information Technology (IT)”. The standard title remains to be: “Information technology — Service management”.

I have written in an earlier post regarding the confusion that exists in this matter.

I have come across more than one organization (Non-IT) who are hesitant to adopt ISO/IEC 20000 – just because the standard title specifically refer to Information Technology infrastructure Library.

I do understand there could be internal, technical reasons within ISO to keep the title as is; however, it is also important to understand the majority of the adopters and practitioners remain unaware of (or quite understandably, don’t care) about them.

And we can also see that this is not just an issue with the ISO/IEC 20000 standard alone.

The global standard for Information Security , ISO/IEC 27001 also carries the title:  “Information technology — Security techniques — Information security management systems”. (This is retained in the latest, 2013 edition as well). (more…)

I finally managed (delay due to my work and other pressures) to go through the ‘Standard+Case’ (S+C) approach that Rob England (The ITSkeptic) has come up through the Basic Service management site as well as the recently released book of his (Haven’t got to the book myself yet, will get soon!).

The concept and approach is definitely pretty interesting and useful in an ITSM (and of course generic Service management) context – more specifically in service support world of incidents, Service requests and problems.

ITIL® has been dividing the support requests (or tickets in a more popular terminology) into Incidents, Service Requests, Problems, Change requests, Access requests etc  – to be handled by respective, best-practice driven, processes.  The process–driven approach of ITIL® (which the framework has been trying to shrug-off not-so-successfully through the Lifecycle approach of V3 and 2011 editions) has been often criticized to create process-silo in organizations.

The S+C approach kind of cuts the support domain in a different plane. Irrespective of the request to IT  is incident, Service request, Problem , change or any other , the approach to the response can be broadly classified into two:

  • Standard: Predefined because they deal with a known situation, known solution, well defined actions etc.
  • Case: An unknown or unfamiliar situation that rely on the knowledge, skills and professionalism of the person dealing with them

ITIL® has references to concepts to practices such as Incident models, Request models etc which in a way relate to the Standard cases. However, it is not as distinctly and prominently established as would be, if someone adopts an approach like the S+C model.

The key points that I like about the model and approach are:

  • It is complementary to ITIL®or any other models. It doesn’t try to say ITIL® is wrong and hence here is the alternate way of doing ITSM. I have a strong belief in the basic structure and principles of ITIL®, and anything that complements or enhances or fine-tunes the existing principles are the ones I personally, would want to adopt.
  • It is very simple(as opposite to ‘complicated’ and not to ‘difficult’) yet powerful– small organizations and those organizations who are not familiar with and/or established the concepts of Incident, Problems, Service requests etc. can still adopt the approach onto their existing practices.
  • Easier way of communicating to business or non-IT and agreeing on timelines, SLAs etc. As Rob has mentioned in the introduction to the model, it is a terminology/approach already in use in many other service scenarios such as hospitals, law and order, etc.
  • The approach of ‘adaptive case management’ and not trying to put Cases into a defined process – this has been a concerning factor for me in ITIL® problem management,  to some extent in Incident/Major Incident handling and in some instances of business requests for new/changed services.

However, the following points are also worthwhile to be noted: (more…)

Many practitioners in the industry try to learn/approach a domain through a framework or standard – where it should be the other way around!  Understanding the specific nature, context and challenges of a domain can make selection and adoption of standards and framework much more beneficial. Understanding the context of  Service management –> IT Service Management and then look at ITIL and/or ISO/IEC 20000 is a case in point. Many attempt to understand IT Service management domain through ITIL and ISO/IEC 20000. 

This problem is not limited to ITSM domain alone. It is equally applicable to Information Security, IT governance etc. 

Just blogged my thoughts on the same on our Wings2i official blog: http://wings2i.wordpress.com/2013/05/23/understand-the-domain-and-then-use-a-framework-or-standard/

Your feedback and comments are welcome

Recently a couple of discussions raised in social media were regarding the clarity between a Service Request and Change. For those who has the right understanding of these two terms, this discussion might look too basic – but my experience shows that many practitioners are carrying some level of confusion on these terms.

Here are the typical confusions/queries that I have seen regarding these in my training/consulting engagements as well as forum interactions:

  • How to differentiate a Service request from a Change request?

Service Requests are those requests coming from a user to the Service Desk (or in some cases, self-help channels) and fulfilled through Request fulfillment. Change requests are requests for modifications required in any part of the Services, Service management systems or underlying systems and components.

Service Requests can include requests for some changes that a user ‘is entitled to ask for’ – often defined as those forming part of ‘standard’ requests from users. To fulfill those Service requests (only those involving changes – not all), applicable change management process (or change model) need to be followed. In fact, In the fulfillment of such Service requests, two (or more) processes might work together – along with request fulfillment there could be processes such as change management, release management (where applicable), access management etc. This is very much like:  for resolving an Incident (or Problem) – you might need a change and hence has to follow change management process.

However, it is also important to note that the changes that can be requested by users will be those minor, operational changes (installation of desktop software/hardware, user id/password changes etc) – and hence will typically fall under Standard Change model (in other words, pre-authorized). So, for fulfilling of those requests, there is no change approval and such detailed change management process is not usually required. (more…)

When the 2011 edition of the global standard ISO/IEC 20000 came into effect, there was a visible interpretation in (at least some portions of) the industry that  the standard has now made itself applicable to ‘generic Service management’ and not just IT.

But in those areas as well, there has been a split in opinion:

A set of practitioners, consultants, auditors etc who believed that ISO/IEC 20000 has really moved beyond an ITSM standard into a standard for ‘Service management in general‘. In other words, this standard can be used to benchmark and certify non-IT Service management as well.

Another set of people (including me) who were not very sure if that was really the case…

Why the interpretation came into the industry?

  • Most of the text in clauses and terminologies of the standard mentioned just ‘Service management’ and nothing specific about IT.
  • The Application Section of the standard stated:  ‘All requirements in this part of ISO/IEC 20000 are generic and are intended to be applicable to all service providers, regardless of type, size and the nature of the services delivered.’

 Then why the doubt or confusion still existed? Here are some reasons:

  • The  title of the standard still read:  ‘Information technology — Service management’
  • The Forward section of the 2011 edition talks about the summary of differences with the earlier (2005) edition of the standard such as:  closer alignment to ISO 9001; closer alignment to ISO/IEC 27001; change of terminology to reflect international usage and so on – but nothing on this significant scope change of this standard.

And more importantly, if you look closer, even the 2005 edition of the standard never mentioned anything specific to IT in most of its text, except in the title! (This in some form, justifies the point about the Forward Section mentioned in second bullet above.)

So is this a change in the standard with the 2011 edition?  Or Is ISO/IEC 20000 intended from a standard for generic service management from day 1?

If so why the title specifically says ‘Information Technology’(more…)