Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive


Thursday, March 29, 2007

How to Fail at SLM with Service Level Agreements

This post is for all of those unfortunate folk that have been told that they must produce a Service Level Agreement or not come home. It is my hope that you can use this article to send to your management team to explain that SLAs without the necessary support do not make good business sense.

“Every day you may make progress. Every step may be fruitful. Yet there will stretch out before you an ever-lengthening, ever-ascending, ever-improving path. You know you will never get to the end of the journey. But this, so far from discouraging, only adds to the joy and glory of the climb.” ~Winston Churchill

Many of us have been in the situation where we are tasked with developing an SLA but have been given no direction. We often begin with the same questions, such as:

  • How do I define it?
  • How do I get IT to support it?
  • How do I measure it?
  • How do I get out of it?

You see there are many requirements which need to be in place to support an SLA with a customer. One of those basic requirements I addressed in my last post called The Practicality of Prioritization.

The following story appears in our newly released book:

 


Defining IT Success Through The Service Catalog

Many organizations that attempt to improve service fail miserably due to the fact that, instead of beginning their efforts with the definition of the service offers making up the catalog, they start the process at the last step - the definition of the Service Level Agreements (SLAs). 

The primary objective of Service Level Management is to improve customer expectation and relationships around the delivery of IT Services. Most organizations are attempting to do this very thing when they begin to establish SLAs. However, they do so with little to no understanding of what the business needs, or is willing to pay for, nor what they can offer and reliably deliver. In addition to this little to no agreement has been gained between the IT technology silos around operational level agreements of how to support and deliver services.

The story unfolds like this: a well-meaning IT professional calls a meeting with his or her Business Customer. This meeting is usually initiated by a demand by senior management or a project task to establish SLAs. The urgency of this demand is aggravated by the analyst organizations which make sweeping statements about the need for establishing Service Level Agreements immediately. The question then is how to develop a SLA in the absence of defined services. Since what is typically measured and understood within IT organizations are the technology domains, SLAs are documented on such things as applications in isolation or infrastructure components such as a server or set of servers. However, none of these things represent the end-to-end service the customer is consuming.

Given this typical senario let us return to our story. Since the individual calling the meeting wishes to be seen as customer-oriented, they start the conversation with typical requirements-gathering questions. The conversation begins like this: “We want to be a value-added partner and want to know what you need of IT so that we can enable your business.” The answer, of course, is: “We need IT services to be reliable, flexible and free.” Translated, this means we want it all, we want it now and we don’t want to pay for the privilege!

Unfortunately, at this point the IT professional, wishing to be customer-oriented, agrees and documents the customer’s wishes in the sacred SLA. However there is little to no ability to measure if the services will be delivered in accordance with this agreement. And there is little to no chance of the internal groups within IT agreeing on basic support policies around priority, escalation and notification.

The end result of this situation is the creation of a document which is unrealistic and has no real bearing on the IT organization’s ability to provide services as promised. The final result of which is failure to deliver on the promises made! What was intended to be a document to improve the relationship and manage expectations became simply a large stick to be beaten over the head with.

By starting the process of Service Level Management before it was understood what IT services the customer needed and was willing to pay for (and how they could be delivered reliably), the IT professional achieved the absolute opposite of the original goal of improved customer expectations.

The reality is that many of us are in this exact situation. We started the journey towards Service Management at the end instead of the beginning and we bare the scars to prove it.

It is my hope that like this quote from Robert Frost that you resist the popular approach of starting with SLAs and instead start at the beginning by defining your IT services. Or at the very least you go back to the fork in the road and begin again down the path that leads in the right direction.

Two roads diverged in a wood, and I- I took the one less traveled by, and that has made all the difference. ~ Robert Frost

Troy’s thoughts what are yours?

 

(5) Comments
Posted by Troy DuMoulin on 03/29 at 05:01 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Thursday, March 22, 2007

The Practicality of Prioritization

An IT Priority Model Cannot Be Relative but Must Represent Accepted Corporate Truth!

Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened. ~Sir Winston Churchill

We live in an age of relativism where high value is placed on the concept of independent thought and self direction. We often take this principle to the point where people are uncomfortable with the idea of taking a stand and establishing absolute truth.

However, there are some places where agreement on corporate truth is critical for successful policy and process collaboration. One of these areas is the policy of prioritization. Imagine an IT department where there is no agreement on how much impact a given incident has on the business customer. Or what constitutes a minor change versus one of significant business risk. In this organization one person believes an incident to represent a minor impact while another believes the sky is falling.

If this sounds familiar then consider that an organization that does not have a solid consensus around a model for establishing process priority has no hope of supporting service level agreements. In an organization where personal interpretation of the situation is the norm there is no real basis for establishing agreed upon escalation rules and change approval models

The ITIL policy of priority is based on the concept that Priority = Impact + Urgency

By looking at something from the combined perspective of Impact (often referred to as severity or degree of failure) and Urgency (time sensitivity and business criticality) we can derive Priority.

They key difference that ITIL presents with the concept of Priority versus the classic usage of Severity is that severity alone does not provide enough context for Prioritization. The urgency factor needs to be added to severity in order to provide an accurate understanding of how to prioritize activity.


Priority Model
Impact is a measure of the degree of realized or potential business process failure caused by an incident, problem, change or release.  In one sense you can equate Impact to equal the extent to which agreed service level agreements are or will be degraded. The scope of service degradation is measured by the number of services, systems or users affected. Generally, impact is differentiated by scope:

  • High: Business Unit, floor, branch or LOB
  • Medium: small group of users
  • Low: single user

However, impact can also be altered by VIP status, which can be based on organizational hierarchy (e.g. executives, VP’s, managing directors) or a particular role (i.e. specific users who justify immediate or special attention based on business role). In the case of users with VIP status, impact can be assigned as follows:

  • High: a group of users with VIP status
  • Medium: a single user with VIP status


Urgency
Since a high-impact incident does not by default, have to be solved immediately, it is not necessarily a high priority incident. Urgency provides a second measure of business criticality, which indicates the necessary speed of resolving an incident of a certain impact. Whereas impact is defined by scope, urgency is defined by time. It is determined by the time sensitivity requirement for a resolution, as measured in terms of financial, brand, or security impact of a particular service’s downtime. For Example: for the same period of downtime, a core business service will cost the business more than a back office administration service. Therefore, urgency is also based on levels of time sensitivity:

  • High: Core Business Service – an activity that has a direct financial, brand or security impact on the business organization (e.g. trading applications)
  • Medium: Support Service – an activity that directly supports the execution of a core business service (e.g. printing services)
  • Low: Non-urgent Service – an activity that does not directly support a core business service and is not time sensitive (e.g. Internal Company Intranet Portal)

This is an example model only but provides a good basis for discussion. They key factor represented in this blog post is that an organization must have organizational consensus around the policy for establishing priority in order to support cross process collaboration.

You will find a podcast on this subject On Pink Elephant’s iTunes Site

New Addition: Based on a comment I have provided a more complex model that reflects an additional example:
Example Priority Model


Troy’s thoughts what are yours?

 

(23) Comments
Posted by Troy DuMoulin on 03/22 at 01:30 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Wednesday, March 14, 2007

ITIL ver 3 The Past and The Future

The Evolution of Service Management Philosophy

It has often been said at that the only constant is change! In the dynamic world we live in this is true of all organic things and ITIL is no different. From its humble beginnings as an internal UK government initiative, to its growth and adoption as a global best practice and standard for Service Management, ITIL has taken many steps along the road of progress and maturity.

The ITIL Refresh Publications & News Letters published by the TSO have given us some interesting insight into the future of IT Service Management as documented by ITIL.

You will find links to these documents on Pink’s ITIL v3 - Information Central webpage

It is my view that ITIL v3 is definitely taking a major step in the right direction. We can observe a glimpse of this from a table that was published as part of the “ITIL Refresh Newsletter 1st Edition Autumn 2006”. For this blog post I would like to call your attention to that table.

ITIL v2ITIL v3
Business & IT Alignment Business & IT Integration
Value Chain ManagementValue Service Network Integration
Linear Service CatalogsDynamic Service Portfolios
Collection of Integrated Processes Service Management Lifecycle


From this table we can identify and interpret some key evolutions in ITSM Philosophy.

Alignment vs. Integration: For many years we have been discussing the topic of how to align Business and IT objectives. We have done this from the assumption that while they (business & IT) shared the same corporate brand they were somehow two separate and very distinct functions. However when does the line between the business process and its supporting technology begin to fade to a point where there is no longer a true ability to separate or revert back to manual options? If you consider banking as an example: The Financial Mgmt. business processes and their supporting technologies are now so inter-dependant they are inseparable.

It is to due to this growing realization that the term Alignment is being replaced with the concept of Integration. For additional discussion on this topic please read the following two blog posts:

Value Chain Management vs. Value Service Network Integration: When reading ITIL v2 you can get the perception that the Business and IT relationship is primarily about a Business Customer being supported by a single internal IT Service Provider (Value Chain Management). Little acknowledgement our guidance is provided about the reality of life never being quite that simple. Today’s business and IT relationship for service provision is much more complicated and complex then the concept of a single provider meeting all business needs. We need to consider that yes there are internal IT functions, but some are found within a business unit structure where others are providing a shared service model to multiple business units. Add to this the option of using different external outsourcing options or leveraging a software as a service model and what you end up with is what ITIL v3 refers to as an ( Integrated Value Service Network). 

Linear Service Catalogs vs. Dynamic Service Portfolios: While ITIL has always been referred to as an IT Service Management Framework the primary focus up until now has been on the 10 Service Support and Delivery processes. In previous versions of ITIL the concept of a “Service” has almost been an afterthought or at least something you would get to later.  Consider that in ITIL v2 the process of Service Level Management has as one of its many deliverables a Service Catalog which can be summarized from the theory as a brochure of IT Services where IT publishes the services it provides with their default characteristics and attributes (Linear Service Catalog). In contract to this a (Dynamic Service Portfolio) can be interpreted as the product of a set of process where service strategy and design conceive of and create services that are built and transitioned into the production environment based on business value. From this point an actionable service catalog represents the published services and is the starting point or basis for service operations and ongoing business engagement. The services documented in this catalog are bundled together into fit for purpose offerings which are then subscribed to as a collection and consumed by business units.

For more information on this subject I would like to refer you to these additional blog posts.

Collection of Integrated Processes vs. Service Management Lifecycle: Based on publicly available information we know that the ITIL v3 core books are structured around a Service Lifecycle. This new structure organizes the processes we understand from ITIL v2 with additional content and processes we are waiting to hear more about within the context of the life span of IT Services.  From this observation we can see that the primary focus is shifting from Process to IT Service. While processes are important they are secondary and only exist to plan for, deliver and support services. This moves the importance and profile of the Service Catalog from being an accessory of the Service Level Management process to being the corner stone of ITSM.

For more information on this subject I would like to refer you to these additional blog posts.

As organizations evolve from a technology focus to a service orientation these core changes to ITIL provide the context and ability to support this emerging reality.

Troy’s thoughts what are yours.

“The system of life on this planet is so astoundingly complex that it was a long time before man even realized that it was a system at all and that it wasn’t something that was just there.” ~Douglas Adams

(3) Comments
Posted by Troy DuMoulin on 03/14 at 12:58 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 2 pages  1 2 >