A supposed to be big news that didn’t make the expected kind of ripples in the ITSM domain recently was regarding the joint venture of Cabinet office with Capita which will have the joint ownership of Best practice frameworks like PRINCE2 and ITIL®.

If you haven’t already, you can read the details of this joint venture here,  here:  and here.

A few other names were being used in speculations prior to the announcement – but the name Capita Inc as the joint venture partner seems to have come as a surprise to many in the domain.

Though I don’t have much first-hand exposure or understanding of the situation and development around that, here are a few observations (aided by opinions and discussions of various experts in the domain) :

  • The announcement focuses absolutely nothing on the objectives or impact on the best practices themselves or to the respective domains – but too much on financials, tax-payers money etc.  This could also be a reason why there have been less ripples in the industry than expected. Good or bad, it throws up unnecessary focus (or at least speculations) to ‘valuation’ of the best practice frameworks – and in turn to that of ITIL®. Stephen Mann in his Forrester blog  felt this was “possibly be the worst advertisement for ITIL® ever released”!
  • For some of us in the ITSM domain who has been constantly complaining or criticizing the way ITIL® was run so far – this could be the change that could bring the change in approach.  For the time being at least that is an optimistic possibility.
  • With the 51:49 stakes-split (in favour of Capita) shifts the governing control to Capita. Will the interest of Cabinet office get limited to just the commercial ROI from their 49% stakes – time will tell. As many in the industry has already commented on, the significant fact here is: the governing control of ITIL® is moving to a public entity to a private company. (In my view, this could actually turn out to be a good thing). (more…)

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

ITIL documentation (Ref: Service Transition Publication) includes Definite Media Library as a part of Service Knowledge Management System (SKMS).  This has always been a key debate points in training and consulting discussions for me – the reasons for the same, will be given below.

I also had an interesting Twitter interaction with Mr. Stuart Rance (one of the authors of the Service Transition publication 2011) on the same, yesterday.  Some  of the points of this discussion also will be explained along with my further views on the same.  Realized later, that the 140 character restriction of twitter was constraining the ability to explain viewpoints clearly and hence this post took shape.

Prior to getting into the specifics, let us look at some of the pointers about the DML and SKMS from ITIL, and based on my interpretation of the same:

As per ITIL 2011:

The definitive media library (DML) is the secure library which contains the master copies of all controlled software in an organization. The DML should include definitive copies of purchased software (along with licence documents or information), as well as software  developed on site. Master copies of controlled documentation for a system are also stored in the DML.  Electronic assets in the DML are held within the SKMS.

The service knowledge management system (SKMS), is concerned, as its name implies, with knowledge. Underpinning this knowledge will be a considerable quantity of data, which will also be held in the SKMS.

My interpretation of the same was like this:

  • Since DML contains some ‘information assets’ such as controlled documentation, technical information about the software etc – these should automatically become part of the larger SKMS.
  • Hence, “DML will be ‘stored’ in SKMS” is a wrong way of putting it. The information assets stored in DML will also form part of the SKMS.
  • There are other service assets / CIs stored in DML such as: Bought-in software with their media, in-house built software etc. These assets won’t really fit in the ‘data-information-knowledge’ spectrum in the SKMS context.  Such assets won’t be part of the SKMS.

Now, in my interaction with Mr. Stuart Rance, he has given me a few interesting view points on this: (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…)

This week, I have completed and published a small paper on our (Wings2i) website with title same as the title of this post.

You can read/download the paper here.

The paper is a summary of some of the critical misinterpretations/misconceptions that I have observed in the Industry so far, regarding the Core concept of ITIL ® : The Service Lifecycle. Such pitfalls can negate or degrade the power of such holistic concept introduced by the global best practice framework.

The Paper looks into the following aspects of the Service lifecycle :

  1. It is SERVICE Lifecycle – NOT Service Management Lifecycle
  2. The Progression of Stages is not Linear
  3. All Stages are NOT Equal!
  4. Stages will and can overlap
  5. Processes can/will span multiple lifecycle stages
  6. The Risk of “Lifecycle Stage Silo’s”

 There might be other such considerations that are important for adoption of the model. Such inputs and any debates on the points that I raised in the paper are most welcome!


What is Problem management in ITSM?

When there is ’unknown underlying cause’ for ‘one or more incidents’, Problem management process is used to find the ‘underlying cause’, convert them into ‘Known Errors’ and ‘Resolve them permanently’.

Problem management can be Reactive (when it is used to do analyze and permanently fix the cause of an incident that just happened) or proactive, where  areas requiring Root cause analysis are proactively identified – through trend analysis, proactive identification of potential issues etc.

All these are fine – but have a very basic ‘problem’:  The whole set of explanations gives an impression that it is all above correcting a ‘problem’ and identifying and fixing an ‘error’.

Why this process should only address ‘Problems’ and ‘errors only? Won’t the same process useful for ‘Cause analysis’ and ‘management’ of any ‘unknown’ element in the Service management?

In a broader sense, we are discussing a process that aims at:

  • Identify an area that requires detailed cause analysis
  • Derive and document the underlying cause
  • Address the cause fully (as required) and further actions on it

Take the following scenarios as examples:

1. After a particular patch/bug-fix is implemented on a Server, the performance of the Server has improved significantly – It is an unintended outcome from the patch update. The concerned technical team is not sure ‘why’ this has happened.

It might be a good idea to do a ‘cause analysis’ in this case to identify the root cause of this positive change in Server performance and address questions like:

  • Is this positive performance change really due to the patch update?
  • If so, which element of the update has caused the improvement?
  • Can this element be used on other (similar) servers to improve the performance?
  • Can this element be included as a part of design document for such servers? (more…)

I make my living from Service management or ITSM in general and ITIL® in specific in majority of cases. My association with ITIL and ITSM is not a forced one, just because it is helping me to earn a living – where as I am extremely passionate about Service management or specifically ITSM as a domain and ITIL® as a framework applicable to that domain.

At the same time, I do criticize inconsistencies and errors in ITIL® documentation (and even more on some of the decisions/practices from the governing bodies of ITIL®) through this blog, which may even give an impression that I am against it and I don’t support adoption of the framework – which just the opposite of truth:

I can see many of the consultants/experts/practitioners out there who criticize ITIL® are in fact passionate about the domain and supportive of the framework, just like me.

The criticisms in this case are more aimed at:

  • Removing/correcting those flaws and making the framework more consistent and strong OR
  •  At least makes the practitioners around aware about the errors/issues/pitfalls/risks.

What is the context here?

A lot of discussions on the internet forums these days tend to go around in such a way that gives an impression, there are only two options:

  • “Full-ITIL” or “No-ITIL”

The arguments tend to polarize into:

  • ITIL® is “THE” framework for ITSM or
  • ITIL® is useless and should be dumped – look at XYZ (or ABC or what ever) as an alternative!

Why is it so? Why can’t it be:

Option A:

  • ITIL is a (more than)useful framework that can be adopted for ITSM in the context of this organization
  • You might also need XYZ (or ABC) framework/standard to complement the practices of ITIL to gain maximum benefit.
  • (More importantly) While adopting, be aware of these inconsistencies, gaps, missing links to be taken care of!

Option B:

  • XYZ is the most suited framework for the context of this organization
  • You can also complement the practices by adopting some selected practices from ITIL

There are enough discussions out there which give great insights into why ITIL® is not a Perfect framework that can be adopted as is. In either case, it was never intended to be!

But there are also enough case scenarios and examples out there to prove that ITIL contains a (much more than) useful set of practices for ITSM.