ITIL – General


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

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

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.

(more…)

Next Page »