What about the customer?

In my ITIL consulting experience, though customer is a term we use more often than not, its the customer who somehow comes up as of the least thought of entities when it comes to processes and implementation. Now that happens because Organizational Change Management is looked at post the design of a solution or a strategy, which I am not sure is the right thing to do.

While any change in the processes or its execution is going to cause ripples in the way things have been working for and worked by customers (often called Users in some situations), it is important to have a selected group review and validate the plans in great detail. This helps any project team build up on customer confidence, take critical execution related feedback, and make amendments in time to ensure customer concerns. Makes the execution easy and adds to the chances of a successful implementation.

Arne Van Oosterom in his recent article on  mycustomer.com has written about Customer Journey Experience and detailed out 10 essential elements of a Customer Journey Map. Read more of the article here.

Context or Stakeholder map

Persona

Outcomes

Customer Journey

Touchpoints

Moments of Truth

Service Delivery

Emotional Journey

Blueprint

Improve and Innovate

Balanced Scorecards and Metrics for Service Support

In this article by Rob England he provides a point of view on the some not so desirable metrics for Service Desk and an approach towards a Balanced Scorecard. What I really admire about Rob’s approach is his different point of view on the usual norms and the way he would force you to validate your thinking and provide a different point of view.

In this article he has written about too much focus on Abandoned Calls undesirable. While it might be ok for an in-house service desk to not give too much focus on Abandoned Call Rate, more often than not SLAs which are written between third party/external service providers and customers have Abandoned Call Rate as an important statistic. This is something that is an indicator of the service to customers and drives customer satisfaction. Rob mentions that too much focus on ACR might force Service Desk agents to finish the calls in a rush, and a similar situation would occur with focus on AHT (Average Handle Time) for calls. I personally feel that these two metrics are an important indicator of the Service Desk quality and need to be measured. Some of the actions which need to be taken with these numbers going up could be

1. Identify a trend in Call Abandon Rate and staff Service Desk agents to handle those volumes (most call centers do that)

2. Identify agents which high AHT and identify reasons for high AHT. This might trigger a need for some training to be imparted to those agents

In my opinion, its not possible to reach a conclusion on these metrics unless a deeper analysis is done on them and over time a consistent performance should take these down the priority list.

The answer is in “HOW”, not “WHAT”

In my experience, its not the “what” framework you are using that helps an organization, its “how” you are using the framework that makes a difference.

This has been validated by organizations that have stayed with ITIL V2, and focussed on improving the maturity and compliance of existing processes, instead of jumping on to ITIL V3 bangwagon after it was introduced. There is another set of organizations that have started to adopt the V3 lifecycle approach and bringing in flavors of process definition and structure  from ITIL V3, however that still needs to translate to being able to execute what gets documented. And no results can be guarenteed unless there is adoption and compliance to the new set of processes.

The thought was triggered by the latest article on ITPReport by Alim Ozcan where he summarises the versions of ITIL and recommends  when to use them. I feel that he is correct, however I also feel that before an organization decides between one of the few available versions and best practice frameworks, a quick analysis of what we want to do, and how we are doing it currently is very important!

A quick checklist could look like this

1. Do we measure current process performance and adoption?

2. If no, start doing that before we decide on a new framework. If Yes, what is our level of execution? are we doing good?

3. If we are doing well on the current set of processes, what do we add to the process  to take it to a different level? Integration? Governance? Services flavor? It is important to benchmark the processes against best practices and a maturity assessment once in a couple of years would help answer the question # 3.

Black and White of Configuration Management

A term mostly used either with printing or photography, but I use it to today in Not Just ITSM to link to two very different thoughts on CMS or Configuration Management System as most would know it!

In the latest DITY newsletter,  Carlos Casanova has written about A-FIRM structure for CMS and mentions CMS as a successful IT System. A-FIRM stands for

A – Architect: Architect and map out your ascent before actually setting out on your climb. If you do not do this, you will be lucky to reach a base camp from where to launch your serious climb.
F – Federate: Determine which camps may already be well established along your climbing route and which you can leverage on your ascent. These are components that you must factor into your long-term solution and are vital to any success you achieve.
I – Integrate: You will not be able to carry all your supplies on your journey so seek out others who can provide insight and assistance. Be on the lookout for those who may have already succeeded in partial ascents and can work with you to reach the peak. There will be times where you will have to leverage these for short periods of time until you can find a more sustainable long-term solution to accomplish that portion of your climb.
Compared to Federated components, these components are ideally just short-term solutions. They may be able to mature into a long term-federated solution, or they will need to eventually be replaced by a different long-term solution.
The key is to recognize which of these two categories they fall into. Wrongly assess a short-tem stopgap measure as a long-term solution, and you may die on the mountain during your climb because of faulty or incomplete data provided by them.
R – Reconcile: This will likely be one of your most challenging tasks because you will undoubtedly face many situations where you need to make a critical decision armed with less-than-ideal data. These decisions will make or break your entire ascent. Choose the wrong data and your team dies on the climb; choose the right data and you have a chance to succeed. Notice that there are no guarantees of success even if you choose the correct data.
M – Merge: Over time, you will identify situations and groups that you can combine to provide more reliable data and/or support you on the next leg of your ascent. You need to carefully execute these mergers to ensure you do not negatively impact the value you are seeking to achieve. Eliminate the wrong data or people, and you endanger the entire mission. Do it properly and you reach the peak faster, with less risk and at a lower cost.

Read the newsletter here or download a pdf here.

On the other hand, Rob England, the IT Skeptic writes at length about CMDB and CMS being an Industry created myth.

These two are masters of their trade, and have very different views on the same topic. In my limited experience with CMDB, I cannot help but agree with both of them right now. Also I feel that CMDB is a term that is very loosely used by many without realizing or knowing the content that should go in there… For a lot CMDB is the solution to all their problems, and now CMS is the solution to all their problems. I, however, think that CMS or CMDB being the solution to a problem is just a hypothesis, which needs to be proven right or wrong after the roll-out. Small or big, simple or complicated, CMDB or CMS, would NOT work, if one is not aware of what the objective of creating it is for the organization and what we want to achieve from it.

Creating a Service Catalogue

Click here for a high level overview of the steps required to create a Service Catalogue, from the art of service. The steps mentioned in the pdf are :

Definition of Service Families

Definition of Services within Service Families

Mapping Services to existing customers

Mapping expectations and dependencies to services

Establish Operational Level Agreements

Establish Service Level Agreements

Establishment of Cost of Services

Steady Stage

By the looks of it, these sound very logical steps, however in my opinion these are very very high level steps and tell you what to do, but honestly not in its complete entirety…

I like the fact that ITIL V3 differentiates between a Technical Services Catalogue and a Business Service Catalogue, however what I do not like is that it uses IT Services in both the definitions. In my opinion, Business Services Catalogue would be for only business services, things which do not have  IT Users in its audiences, and IT Services Catalogue would purely focus on those services which are used by IT Users (including Business Users)

BSC could have services related to business applications or similar, services that lead to generation of money for the company

TSC could have services related to IT applications or similar, services that facilitate the use of IT in the organization.

More on this sometime later…

When is it an incident?

Rob England in a recent post brought up the topic of distinction between a Call and Incident in the ITIL V3 Books! I then went to the book and started reading through the IM Process and did not really find a classification there, which Rob also confirmed in his update on the post here.

Now if I look at it closely, ITIL V3 book in a way achnowledges that the source of an Incident can be more than one places, e.g. Event Management, Web Interface, User Phone Call, Email technical staff, but really does not talk about where a call or an event would become an Incident (Fig 4.2 in the Service Operations book)

In my experience with two IM Processes here is how it worked

1. The User Interfacing process was Call Management (based off IBM EOPs) and it determined where the call should go and be tracked. In case of an Incident, it would trigger an incident management process for service restoration and incident resolution, for the rest, it would either end at the Service Desk as a question which was answered or a first contact resolution or would trigger a request fulfillment process. This was based on IBM EOPs, which I felt were much more comprehensive and implementable than ITIL recommended processes.

2. Everything that comes to the Service Desk is a Service Management ticket, and becomes an incident ticket only when its determined that it is an interruption to service and has an SLA impact

In both the cases, there was a many to one relationship between the calls/SM tickets to Incidents… multiple calls could be logged or multiple SM tickets could be logged for the same issue if there were multiple users calling or logging tickets themselves using a web interface, however these tickets would be associated with one single master incident which would then be published and pursued  for resolution and service restoration.

From an ITIL V3 perspective, I think one would have to leverage on the Event Management process to be able to log events and then classify them into Incidents, however leaves the How-To questions, and Service Requests aside, and does not tell how to deal with them.

Building and maintaining ROI – Article by Stephen Hirsch from SAP

Was reading through an interesting article by Stephen Hirsch from SAP Education… he in this article talks about building and maintaining ROI through performance management. What I like about this article is that it does not talk about typical performance management of an application or a system, but is talking about a whole cycle of organizational change management to ensuring that the organization achieves what it set itself up for through this change.

The phases that Stephen has stressed on are

• Change Management
• Assessment, Strategy and Development
• Knowledge Transfer
• Operations
• Performance Management

My view on this

Knowledge transfer and Performance Management would be two very very important steps that would prove instrumental in the success of a project/organizational change!

Like Stephen also mentioned in the article that most users would rely on quicker methods to gain information and not the large documents or LMS modules post implementation, there is a requirement for consistent and crisp information flow and availability of that simple information to do the job well!!!

What is mentioned as performance management in this article is something that I percieve as process adoption… and without well built checks (not controls as yet) one would not know how well the organization is doing! Do going back to the Strategy and Development phase, one of the key things is to identify

1. How do we know we are successful?
2. What do we measure to substantiate the achievement of goals?
3. What would be the error correction or process adoption plans in case of things not going as expected?

You can read the detailed article here (Requires registration).

Image source : End-user Performance : Building and Maintaining ROI article from SAP

Short (text) case study of two financial organizations and ITIL

Click here to read a short case study of how ITIL alignment has helped two financial institutions.

Following the ITIL processes of incident, change, problem, configuration and service portfolio management has saved the company approximately $20 million through improved processes and efficiencies, according to Paul Ruppel, production systems consultant lead at Wachovia.

From how I see it, the two key items that would define the success of any ITIL related initiative would be

• To identify the problem.

In ITIL terms, do an RCA of the current situation and perceived problems which the IT is facing and then prioritize the solutions. Is it too many incidents? Is it too many changes? Is it the time taken to resolve incidents? Is it the inability to forecast business needs? Is it not meeting SLAs? what exactly is the problem that you are trying to handle with getting ITIL into the picture? or is it that you are just trying to mature an existing process?

• Prioritize.

It would never be one single reason that would cause something to function incorrectly. Mostly in the IT world, there are multiple reasons why something is not functioning the way it should be. And we need to accept that not everything can be resolved together. So a sorting has to be done. A 2X2 matrix should help to have a priority in place… Expected benefits on one axis and estimated effort on the other.

Project Failure and Success

Link to Six reasons of project failure. I got this article on a post written by Michael Kringsman where he has referenced this blog post by Michiko Diby. Michiko in his post has talked about the 6 reasons of project failure in detail and also has links to explain the reasons.

The reasons which have been highlighted in these posts are:

Intent Failure – Occurs when the project doesn’t bring enough added value or capability to beat down the obstacles inherent throughout the process. This suggests the original intent of the project was flawed from the beginning.

Sponsor Failure – Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.

Design and Definition/Scope Failure – Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.

Communications Failure – Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.

Project Discipline Failure – Occurs when process/project methodology is allowed to lapse so that the mitigation factors inherent in the process are never used.

Supplier/Vendor Failure – Occurs when the structure of supplier /vendor relationships doesn’t allow for communication and adjustments.

In addition to these, here are a few that I added in the comments:

• Change Process failure – where the scope and deliverables keep changing and there is no set/agrees change process to update the scope
• Skill Failure – when the right skills are not identified for a task and it takes longer than expected
• Stakeholder identification failure – where the reviewing authority/decision making authority is clearly identified
• Turnaround time failure (similar to Project Discipline Failure) – where the participants other than the key project team members fail to revert back in time

Michael Kringsman has a post on IT project success as well which can be read here.

Text in italics is from Michiko Diby’s post, and the clip-art is Microsoft PowerPoint

Responsible and/or Accountable

There are specific differences in the dictionary meaning of words accountability and responsibility. In the ITIL world, we also use these terms and often in different contexts too…

When we write accountability, we are referring to a role which oversees a specific function, action or responsibility

When we write responsibility, we are referring to a role which is actually performing the function, action or activity within a process

e.g. the roles of Process Coordinators vs. Process Owners… Mostly Process Owners would be accountable for the process quality and adoption, however its the process coordinator who is actually ensuring process quality by continuously looking at the data, identifying training needs and establish error correction plans…

In one of the projects that I worked on to improve process definition and introduce process updates, a role of Outcome Manager was defined. I like that term! It simply mentions the responsibility of that role as soon as you read it! I hope to have such relevant roles attached to ITIL Process documentation too!

Words like these are commonly referred to in the RACI charts, which are also called SOD (Separation of Duty) Matrix by some organizations.

RACI

Read a few more thoughts on RACI in ITIL by ITSMwatch columnist David Mainville here and a good article on wiki here.