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

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

A frequent discussion we have in most of the training programs and consulting engagements is about clarity on handling of “Potential Incidents“. On my previous post about Event vs Incidents, JJ has commented with a similar query:

What about those events which are likely to become an incident?

For Instance, Internet Link utilization increased from 60% to 70%. Say my threshold is 75%(Warning) and 80%(Critical) and the utilization increases to 70% on Tuesdays and Wednesdays, shouldnt an incident be created. Because Incident also includes degradation of service.

Since it is a common discussion, thought of putting this as a new post.

First of all, let us divide the context into two parts:

  1. How will this be treated within event management process
  2. What response will be appropriate from event management for this (in other words, what process/action will be triggered by event management process to handle this event)

Since the utilization is reaching a level close to (not equal to more than) the threshold or critical levels, it is still a “Warning” event (Unusual operation) for event management process – and not an exception. As it hasn’t reached the threshold nor critical level of utilization, we can safely assume that there is no ‘degradation of service’ currently. Hence it is not yet an Incident. Yes, this can be a potential incident later – if not handled.

This is my take on such scenarios: this event is actually detected NOT as part of ‘Incident detection’, but as a part of ‘Capacity Monitoring’ (iterative activities of capacity management as per ITIL) . The thresholds and guidelines for these event should be established by Capacity management process. Capacity management can give an instruction to create an incident ticket, if the utilization reaches or crosses a critical limit at any point. However, the first objective of capacity management is to identify issues concerning capacity, before it start impacting business. That is the reason they are setting thresholds adequately below the critical limits for taking proactive action before it starts affecting the service/business. (more…)

Just finished our final batch of ITIL V3 Manager Bridge this week – final because of APMG’s announced ‘Hard-stop’ of V3 manager Bridge certification on June 30th, 2011.

For ITIL V2 Service Manager certified professionals, the situation is not as bad as many of them think, even after June 30th: The available path towards ITIL expert certification are specified by APMG here:

As per this communication, a certified ITIL V2 Service Manager can still get to ITIL Expert Certification faster, by completing the following THREE certifications:

1. ITIL V3 Foundation (or V3 Foundation Bridge, if they have already done that)


2. ITIL V3 Intermediate Life cycle : Service Strategy OR Continual Service Improvement


3. ITIL V3 Managing Across Lifecycle (MALC)

Personally, I don’t really understand the logic of the second requirement there : Service Strategy OR CSI. But that is the decision and announcement from the Accreditation body.

However, I definitely see some confusions among students/candidates for certification, caused by the v3 Qualification scheme guide of APMG (that was published in 2009 – and still live on their site, no further updates on their site, hence we can assume that is the current one):

The criteria for ITIL Expert indicates shows the following: (more…)

ITIL Certifications are still in demand – and most probably, in growing demand.

Training organizations are asked, and they work towards “Passing rate” claims; some even with commitments – or Warranty of passing.

But what about Utility of ITIL trainings and certifications? Are they really improving the knowledge level of the people? 

Had an “interesting” experience of interviewing a couple of persons who are Certified ITIL V3 Experts last week: Those have completed ITIL v2 foundation, ITIL V2 Service Manager and ITIL V3 Manager Bridge certification; whose resume boasted of 7-10 years of Service management experience with few of the Largest global IT Companies.

At the end of the interview, I was particularly sad: Not about that persons, or my (and their) wasted time; but regarding the sorry state of ITIL Certification and its value in the Industry…

Note: The objective of this post is not to blame or ridicule those particular persons; I am actually trying to high-light the knowledge level or understanding of a person who is Certified as ‘ITIL V3 Expert’. Enough has been discussed on the internet as a medium about this concern – but here is a live scenario as it evolved.

What will the image or value such a certification be holding across the industry, if the so called ‘experts’ have a knowledge/understanding level such as this.

I am giving below a recollection of a few questions and answers from the interviews (it is not verbatim or exact words used, but as per my memory- However, absolutely no exaggeration is applied here) :

Q1: What are the key changes V3 has brought in compared to V2?

A: See, there are a large number of concepts and processes that are included in ITIL. When you accommodate all these concepts into two books, the books become very big and complicated, and hence in V3 these set of concepts are re-organized into five books covering the whole life cycle.

Q 1a: So, are you saying other than the structural changes in documenting the practices, there are no new concepts/changes brought in by V3?

A: (After a pause) Well, I don’t think so – nothing other than minor terminology changes


I am yet to see any convincing explanation on why ITIL V3 has done away with the concepts of ‘Problem Control’ and ‘Error Control’ – the two parts of the Problem management process that used to be there in V2.

  • If this was not required/ if that is not a best (good) practice, why was that in V2?( I believe there is a value in subdividing the process into those two stages, which I will explain in a short while)
  • Was it, in any way causing any sort of issues in implementing and following Problem management?
  • Is there a real value in making Problem management one consolidate process flow, as it is in V3? (In other words, is this a better practice, compared to the concept of having Problem and Error Control?)

Why are we concerned with this removal?

I used to find the earlier concept of Problem and Error Control a very logical one. Here are some of my arguments in support of  such a subdivision into two stages:


Next Page »