Service Matters! ITSM & IT Management

Recently, I came across this blog from BMC's Ken Turbitt on Customer Focus. As Ken says (and of course ITIL V3 too), IT must have Business focus, with Business being IT's customer. While that is true, the main theme for Service Management continues to revolve around ensuring an excellent end-to-end Customer Experience. And having a Customer Focus is critical for that.

Over the last few weeks, I saw some amazing customer focus in action and experienced first-hand excellent customer service, that I wanted to share with you.

The London Bikeathon is an annual cycling event organized by the Leukemia Research Foundation based in the UK. Well, this being my first bikeathon, I decided to register for the City ride - a 26 mile stretch that took me and another 5000 participants through the heart of London - the Thames Barrier, Canary Wharf, London Eye, St Paul’s Cathedral, etc.

Perhaps, some of what I experienced might appear as relatively non-extraordinary and fairly straightforward events. Possibly they were. But then again, you can also argue that managing an IT Service is also relatively straightforward – after all, what’s the big deal about fixing a bug, determining the root cause, raising a change and so on. Right? Hmmm ... then I wonder why most IT organizations still struggle to deliver even bare minimum good customer experience

Anyways, back to the bikeathon. So, there I was - a customer this time and I must admit, with my ITSM glasses intact. And here's how the world looked to me with my glasses on –

Great Communication – There were posters all over town
It all started when, four months before the event, I came across posters - fabulously visual ones - all around town announcing the bikeathon. Standing in front of one such poster, it was an instant decision – just had to be a part of this. Talk of great comms! So what does that mean in our ITSM world? Process flow posters?? Ouch ... I dislike them intensely! But how about Visual Roadmaps? One of my former clients, who heads the ITSM program at his organization, goes out of his way every six months to publish visual roadmaps showing where the program is headed. Simple and visual – these roadmaps really reinforce the message.

And I registered
So, having decided to participate, I registered using the simple online user interface. Straightforward. But what struck me was the non-intrusive way in which the process led me to set up my own justgiving.com webpage to further promote the event and raise funds. In our ITSM world, how “smooth” are our interfaces? For starters, are you able to intuitively link your incident tickets to changes, or automatically revise your Projected Service Availability based on changes going through?

Then the Big Day arrived …
The first thing that struck me as I started out on the bikeathon was how this event brought together so many diverse people towards a common cause. A common cause – a goal – raise awareness, raise funds and have a good time doing it. Simple and clearly stated.

Well finally, the incentives - I got a Gold Medal !
Serious. Alright – so did a bunch of others who crossed the finish line From an ITSM perspective, that tells me to keep thinking about innovative, and yet very personalized incentives. I know one organization that instituted an award of a thousand dollars every month to the person writing up the most meaningful Post Implementation Review on a Change Request. And that’s only a start. The whackier the incentive, the better.

So, there it was – coming together of all these individual pieces to deliver amazing service, leaving one totally delighted customer – me.

If you ever get a chance to participate in the London Bikeathon, go for it ! Meanwhile, I am looking forward to my next big biking venture - it's the London Duathlon this time.

Till then - happy biking, running and managing your IT service!

Posted by Arvind Raman at 04:17 PM | Permalink | Comments (5) | TrackBacks (0)

Last month I was speaking at the CSI Net Sec 2007 conference around Identity and Access Management a key topic within IRM domains. Overall this was a very well attended event featuring various themes and topics.

It dawned on me during the show, that fundamentally what was happening was a very well structured collaboration forum. People coming in and sharing a range of experiences in different industries, initiatives and focused content.

Much of this has parallels with the manner in which an Information Risk Management (IRM) engagement is structured.

When we seek to evaluate the risk to a particular control, there are differing opinions on the nature of the risk, the actual impact to the asset and the business drivers that influence the risk.

Consider the following scenario

During the annual controls assessment, it was discovered that there were a couple of mid-level employees who had full access to product specs and supplier sourcing information. However it is not clear from the available documentation, if a review of their accesses was being done periodically by their manager. This is immediately flagged as a significant control failure.

When the issue is brought up for remediation, the technology folks pointed to the 35-day password reset in built into the application and the manual check of access levels put into place the week before. So as it turned out, much of the assessment was focused on reviewing the documentation and not on talking and learning from the folks who work with the process

How can pre-audit or technology folks have an opinion that is consistent with each other's viewpoint? The key word in this case has got to be 'collaboration'. Unless one is able to partner with the other side, spend some time in understanding the issues, and discuss the points of contention, a one sided view will not go very far. We end up into a ‘Your word versus mine’ mode.

Can one group conduct an independent controls assessment without seeking the inputs of the target groups? How do they gather the right levels of information / evidence? Who owns the remediation process? How can remediation steps be completed on time?

Once you inject the changing regulations and the dynamic business environment, it becomes all the more certain that a one sided view of Information Risk will be quite shortlived.

Lastly what comes down to as the biggest case for collaboration is that since it is people who man various business processes, they are quite likely to change the processes in small or big measures.

Posted by Ramshankar Ramdattan at 06:21 AM | Permalink | Comments (1) | TrackBacks (0)

In my earlier blog on Change Management metrics, I wrote about how several organizations use total number of Changes as a measure of the success of their Change Management process. Here, I would like to share with you some practices I have found useful in deciding what type of metrics to measure.

But again, be ready to answer more questions! Consider these for starters:

• What level of process maturity are you at? If your Change Management is just taking off, consider more process measures and workload measures i.e. start by measuring activities. Do changes have back-out plans? Have they been tested? What is the break-up of the type of changes? And such metrics.
• As your Change Management process matures, move towards more business-outcome / output measures or what I like to call "nirvana metrics". My personal favourite is the reduction in dollar (or whatever currency you use) impact of changes. Nothing more persuasive than showing the linkage to $. But continue to include measures from all three categories recommended by ITIL V3 - outcome, workload and process metrics.
• And despite all this, what do you do if your leadership still insists on reviewing the total number of changes and using that as the basis for judging how well the process works? Well, here's one option - not a perfect solution but something that I have seen work well. While reporting on number of changes, break it down by:
• Standard Changes as a % of the total number of changes - the higher this %, the better. Why? Standard Changes are pre-approved or perceived to be relatively safer changes whose impact is understood and approved. So, more the number of such changes, higher the chances of being able to understand impacts. And more importantly, build in a mechanism of progressing "routine" changes to standard changes. An easy pitfall is defining a bunch of standard changes at the outset while building out the Change process, but not reviewing these over time.
• Emergency Changes as a % of the total number of changes - Monitor these very closely. If you can show a drop in your Emergency Changes, you have a very good chance of keeping your environment safe. I recently came across a report from Forrester (you may need a Forrester login to access this report) that suggests that the average percentage of changes that are emergency changes varies between 12% and 18% for most IT organizations. That's a good target to start with.

Is that it?

So, is this a comprehensive list of best practices for measuring your Change Management process? There's a lot more ...

Additionally, over the last year or so - Rohit Nand, a fellow blogger on this site, and I have developed a simple framework to help IT Service Management (ITSM) programs structure the way they measure and report. I am convinced that a structured approach to measuring and reporting is the backbone of any successful ITSM program. Keep a look out for that one ...

Meanwhile, what type of metrics do you measure? And what success are you having with your current measurements and reporting mechanism?

Posted by Arvind Raman at 10:10 AM | Permalink | Comments (0) | TrackBacks (0)

The total number of changes has gone down - our Change Management process is a success ... Is it?

A while back, I was assisting an organization to implement ITIL based Change Management process. Apart from (the usual?) complexities of implementation, something that struck me was the trigger for this implementation. "There are far too many changes within our organization - we need to reduce the total number of changes".

So, why am I writing about this? Well, for one, I am still quite amazed by the number of organizations that use total number of Changes as a primary measure of how successful their Change Management program is.

Does it make sense? No? So, is "total number of changes" a wasted metric? Not really. Arguably, it is a relatively easy and very visible metric to measure. But is it sufficient? Does it give a sense of what impact these changes have had on services? Does it indicate whether testing happened rigorously? Or, for that matter, does it even indicate whether basic adherence to process happened or not - such as having a back-out plan, impact analysis carried out, etc. Obviously it's not a stand-alone metric.

So then, what's a better measure? Hmm ... we'll get to that in a bit.

V3 on Metrics

So, what does ITIL V3 have to say about metrics? And specifically what kind of metrics does it recommend for Change Management?

Moving beyond the traditional V2 approach which outlined a bunch of Critical Success Factors (CSFs) and Key Performance Indicators (KPIs), V3 offers a simple but rather interesting way of categorizing metrics. As an example, KPIs for Change Management, described in the Service Transition lifecycle, include:

• Output Measures - Metrics that measure the outcome of the process or answer the question - has it made a difference? Examples include reduction in the disruptions caused by unsuccessful changes.
• Workload Measures - Metrics that measure how many changes are being implemented in the environment or the volumes. And this is where our much-maligned but ever-popular metric of total number of changes fits in.
• Process Measures - Metrics that measure in-flight performance, including perceptions and satisfaction levels with the overall process including speed and ease of use.

So, what metrics should you be measuring? All of these?!

In my next blog, I would like to share with you some practices I have found useful in selecting which Change Management metrics to measure.

Oh and by the way, in case you are curious about what happened to the organization where we started out with reducing the total number of changes: We did manage to reduce both the number of changes as well as the business impact of those changes. But was there a direct co-relation between these two? Possible, but highly debatable!

Posted by Arvind Raman at 01:57 PM | Permalink | Comments (5) | TrackBacks (0)

The split of sales and delivery is well understood in traditional services organizations. The Sales team reaches out to customers, understands requirements, gets the order and then manages the customer relationship on an ongoing basis. On the other hand, the Delivery team is responsible for ensuring services are provisioned, as agreed in the Statement of Work. In some cases the Delivery team is dedicated for customers, in many cases it might be shared.

This concept is being adapted by quite a few IT organizations too where a split is created between a Demand organization which manages client relationships and a Supply organization which is a factory delivering the “goods”. David Mark and Diogo Rau of McKinsey talk about this on cio.com in this article.

Earlier last year, I was helping a large wealth management organization re-design their Production Support organization structure. The exercise was driven by two key challenges they were facing – a) Their organization being perceived as largely being reactive and unresponsive both by the Business and Application Development teams, and b) Inadequate focus of the team on quality and process improvement. The Production Support organization was split up into six teams as per Lines of Businesses (LoBs), Each team was headed by a person designated a “Function Head”, and All Function Heads managed their respective teams which were spread across geographies in their own unique ways.

We performed an in-depth analysis based on interviews and workshops across the Production Support organization, Business stakeholders and also the Application Development owners. What were the learnings? -
1.The group’s face-off with Business and Application Development teams was not well structured and consistent
2.Given they were always in a fire-fighting mode, Function Heads were limited in their capacity to do relationship management work such as joint planning, regular reporting and communication
3.Role clarity issues were reflected in multiple levels participating together in the same meetings
4.Quality issues due to inadequate process standardization across teams

While what came out as findings was not entirely new, putting the analysis in perspective did help us quickly zero in on possible solution options. For one, there was a clear case to separate out a relationship management (a.k.a. Demand organization) layer which would be responsible for liaisoning with the Business and Application Development teams and specifying requirements and specifications to the core delivery organization (a.k.a. Supply organization). The charter of this team was defined to include – Participating in strategic and tactical planning for the LoB, Managing the Service Level Management process based on Business expectations and delivery costs/ capabilities, Managing funding and budgeting, Conducting periodic service reviews and Managing client issues and complaints.

In my next blog, I will talk more about how structure issues impact quality and process improvements.

Posted by Rohit Nand at 10:25 AM | Permalink | Comments (0) | TrackBacks (0)

So, who in your organization is championing your ITIL Service Management (ITSM) program? The CIO office? Does your CIO understand or speak ITIL? Or is it driven more locally through pockets of excellence within the Infrastructure and Operations groups?

There appears to be a good amount of euphoria within the industry that the refreshed service lifecycle approach in V3 will put it straight on every CIO's radar. In the article ITIL Dons a Suit and Tie, published on searchcio.com, Linda Tucci suggests that "CIOs especially, should find it of interest". Similarly, Brian Johnson, one of the original authors of the first ITIL books, in his article ITIL Framework finds new stakeholders with V3, talks about how V3 discussions will now move to the executive level. Whether these statements prove true or not remains to be seen.

Meanwhile, the question still remains as to how much benefit the CIO's influence brings to an ITSM program's success. Let me lay out a simplistic scenario of how the CIO influence may impact two organization's desire to implement an ITSM program -

• Organization A - "CIO's ITIL mandate" or "CIO says ..." is the mantra that goes here. The CIO understands, and what more, even speaks ITIL! (And I have personally been involved in or know of several such organizations.)
• Organization B - The CIO and his senior leadership are quite "ITIL agnostic". In some situations, you are even advised not to utter that four letter word.

So which organization has a better chance of success?

One thing few people will dispute is that an ITSM program initiated from the CIO office has a much higher chance of successfully taking off. So, potentially, organization A could get off the ground faster and successfully kick-start its ITSM program. And well, starting the program is, if not half the job done, certainly a substantial portion of it! Interestingly, that does not mean that Organization B will not get it right.

But the key here is not where it is coming from, rather how it is driven on an ongoing basis. Once the initial euphoria has subsided, how do you drive a program on a day-to-day basis? Given that most large ITSM implementations typically run into 2-3 years, what does it take to keep the ITSM program meaningful?

The "Chief ITSM Officer" and Co.
A while back, I came across a rather interesting article published by Wharton on the Chief Receptionist Officer and how Title Inflation has hit the C-suite. While I am yet to come across a role by the name of "Chief ITIL Officer" or anything to that effect, I think calling out a separate senior leadership role focused on delivering ITSM is quite effective in ensuring accountability and continued focus. Does this need to be a dedicated role? Or should it be combined with Infrastructure Operations? Or perhaps Application Production Support? You decide. Consider these for starters - how large is your organization, how many and which processes are you starting with, what is your existing maturity level (also see my previous blog on V3 Readiness Assessment). Along with these, build out the organization to support such activities. Invest in setting up roles and responsibilities for process owners and process managers.

Metrics, metrics, metrics: Do the numbers make sense?
Irrespective of whether the ITSM program has been initiated through the CIO office or not, eventually it all boils down to being able to demonstrate quantifiable benefits. Have you been able to improve availability? Has your change related dollar impact gone down? Across the program as well as within specific processes. One of the simplest things to say or write but disputably one of the hardest to get right  ... but let me save that for another blog!

Net net -

• The "CIO says" mantra definitely helps to kick-start, but you still need to drive your ITSM program continuously, whether or not you call it ITIL
• Getting the numbers game right is key

Posted by Arvind Raman at 04:57 PM | Permalink | Comments (1) | TrackBacks (0)

After some Google-ing, I was able to find an interesting article on this topic here.

Posted by Adarsh Kumar at 12:13 AM | Permalink | Comments (0) | TrackBacks (0)