Tuesday, 26 March 2013

Your IT Service Delivery Manager Wears Many Hats

We all know that there are many wheels in motion to ensure that a customer has a great, consistent customer experience. At what point do we require the use of a service delivery manager to ensure that this all happens? The key question to ask is who is performing this function now? It may be likely that this is being handled by many resources with duplicating effort and seemingly no major improvement.

We need to take a look at this from a couple of viewpoints. From a customer experience standpoint as well as what makes sense operationally.
From the customer experience there may be a sense that an escalation to the service desk starts off good and then seems to sputter out, where they are left to sit and wait or they feel the need to see what the holdup might be.
Operationally we may have identified that there are strong processes in place for customer support, so how can we leverage the processes to achieve the desired outcomes for the customer. We may need to take a closer look at the way our process works. The individual components might be working from the perspective of the support teams but what about the whole. Are there optimizations that can be made?
Take a close look at the service from an end to end perspective in this example:
Now this example takes into consideration that the Service Desk is not 24x7 but the reality may be that the customer does not see it that way. From their perspective this was broken yesterday.

The end goal is to make sure that customers are happy with their experience as that relates to the service desk and all support services. The role of the Service delivery manager is to ensure that we put the Operations and Customer components together to – deliver service.
Some of these include:

IT Operations Responsibilities
·         Ensure we have, and meet SLA’s
·         Work with IT teams to ensure that resources are appropriate top deliver expected service
·         Make sure there is a procedure for major incidents and there is a manageable way to follow through

Customer Experience Requirements
·         Manage customer expectations
·         Reviewing and ensuring SLA targets are met for availability and service
·         Ensuring that continual reviews are done to ensure service delivery continues to improve
·         Become the voice between the customers and support where needed

Once these are identified it will be up to the IT Service Delivery Manager to ensure that they collaborate with the IT Operations teams and the customers to ensure an improved customer experience.





Feel free to connect with me on Twitter @ryanrogilvie and/or on LinkedIn

If you like these articles please take a few minutes to share on social media or comment

 

 



 

Friday, 22 March 2013

IT User Access Reviews – It’s a dirty job but someone has to do it.

Under the umbrella of SOX, we may be required to ensure user access is accurately administered in our network and critical in-scope financial systems. Since that is the case we need to coordinate Quarterly Access Reviews (QAR) to confirm that only active employees and contractors have access to these systems, and that the users associated access is appropriate for their job function.

Consistent with SOX requirements, the results of the QAR review will be signed off by the appropriate Business and IT Owners, to attest that only the employees and contractors approved by the business units have active accounts and authorized access to our environments.

Where do we begin?

Scope – always seems to be a common theme, but is crucial to ensure that we know exactly what to review. The scope for these reviews may be defined differently and may change for each quarter depending if there is a change in applications used, or changes of a corporate nature.

Next we will want to take a look at a few components to get the review off to a good start:

Step 1: Review & Clean-up

The purpose of this step is to review the current state of our environments and identify any areas that we already know need to be cleaned up. After the actual QAR you will identify areas for improvement which you can summarize in a post review document. Key things to determine

Step 2: Pre-Implementation
 
A few things you should nail down before you begin the review:

·         What are we going to review – Scope

·         Identify who the business application owners are (if you don’t already know)

·         Determine the source of truth of who the “active users” are

·         Identify who will generate the list of application users and their current roles

·         Put together a training package for all the participants – it is possible that they have not done this before

Step 3: Implement Review Process

The purpose of this step is to conduct the physical reviews of in-scope Applications for the quarter. The “reviewers” (whoever is designated) have been given responsibility to ensure that the Quarterly Review of User Access rights to in-scope SOX systems are scheduled and completed in a timely manner.  The following is a list of tasks that they may be accountable for:

1.     Implementing the schedule which will include the period under review, the start and stop date for the review, list of in-scope systems under audit for the current period, and the associated Business Application Owners.
2.     The “reviewers” will coordinate the following activities:
a.     Obtain a list of Active Employees and Contractors from the source of truth.
b.     Trigger the appropriate Business Application Owners or delegate reviewers to perform the review.
c.     Monitor the progress of the review and follow up as necessary.
d.     Verify that the review has been completed as required including the appropriate signoffs by the Business Application Owners.
e.     Implement any access changes identified as a result of the review in accordance with the IT Change User Process.
f.      Obtain Internal / External audit results and review as part of post-mortem.

Step 4: Elevated Access Review Process
 
An elevated access review will also be required to determine who has access to what impacted systems from a database level for example. You will need to:
·         Identify the infrastructure which is impacted by the above SOX applications.
·         Extract a list of all elevated accounts and determine who has access to them and when they were last logged on or had the password changed
·         Where applicable remove access to accounts or accounts in their entirety as they applied
 
Step 5: Results
 
After the completion of the review, and all subsequent activities have been completed, you will be able to review the results and findings. It will be from this step that you will identify any additional process gaps you were unaware of and may need to correct before the next review. It is at this time you should create a document that outlines the findings and share them with the appropriate stakeholders.



Follow us on Twitter @ryanrogilvie

 

Wednesday, 20 March 2013

Managing Modes of Escalation


I recently was experiencing some issues with my local ISP which required me to contact their customer service line for support. The choices which I was given to interact with them were to either call their 1800 number, or they had a messaging app on their home page. I decided to hedge my bets and call the 1800 number as well as leveraging the messaging tool.


Once in the tool I was prompted to provide the reason for my issue and there was an icon indicating that I was awaiting a response. Meanwhile, after dealing with an almost painful amount of “press 1” for this and “press 2” for that, the computerized voice on the line indicated that it was going to be approximately several hours to wait for the next available representative. Fortunately the messaging tool provided a much quicker response (within minutes).
,
After indicating my issues and having them rectified I asked the Customer Service rep, why there was such a gap in the two forms of support. They indicated that while the vast majority of people still like to use the phone, there was an ever increasing demand on the use of the messaging tool. The CSR went on to say that this method was far easier for them since they could cut and paste links to info, how-to’s and even upselling much easier. They also indicated on average the same calls were handled in a fraction of the time since they did not have to explain as much.

This interaction started me thinking about what areas for improvement could be had in my own service desk experiences. Depending on your setup (phone, email etc) you may need to start thinking of terms of the customer experience while what you are doing may make sense now it might not always be that way. The saying goes “You can’t know where you’re going until you know where you’ve been”. To best determine what gaps in resolution times exist we need to determine areas to target

What metrics really matter?
We can track all sorts of data on what the Service desk is doing but the heavy hitters are going to be:

·         Customer satisfaction

·         Costs per contact

·         Productivity of staff

·         First call resolution

Identifying where we are enables us to determine where our customers want us to be. Let’s assume for a moment that we currently handle our requests and escalations from the user base with emails and in critical incident situations through phone call escalations. Performing an analysis of the requests we may determine that a good percentage of the requests revolve around questions, and would be training issues. A further investigation reveals that when added up, it equals a FTE each week. If we had a solid knowledge management policy we could better utilize this staff member to handle other escalations. This minor improvement could reduce the turnaround of escalations even further.

The other consideration we may need to make is the turnaround on the emails that we receive to handle the requests. It’s natural for people to find the quickest way to do things. If they determine that the path of least resistance is a phone call then that is what they will do. This may impact the service delivery for phone escalations until rules are put in place to account for that. These rules may in turn cause it’s their own level of dissatisfaction, so finding out how our customers want to connect with us is important.

In addition to what our customers want we may need to take a closer look inward to see how we collaborate as an IT team. Some things to look at would be:

·         Are there areas where we can improve in our own interactions  to streamline service?

·         What tools do we use every day that we could leverage?

·         Are Blogs, Wiki’s, YouTube, even online communities like Twitter and Facebook something to consider?

As you implement these steps make sure that you continually review what you have done and what did or didn’t work. It’s important to remember that you can learn something from the mistakes that are made along the way.



Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn




Thursday, 14 March 2013

Change Management – Common Challenges


I have had the good fortune to work in some environments where the Change Management process has been pretty solid, with some small exceptions. Sadly this is not always the case and in some organizations the process seems to be about as simple to organize as nailing jelly to a wall. The way to make improvements on these is to break down what’s working well and what areas need some improvements
Let’s review a few of the common issues that manifest and ways in which we can navigate around them.

Challenge 1 - Change Management has value
While it is more common today than ever that people see the true value of a change management process. There are always going to be those who don’t agree. It is to that degree that we need to provide metrics which support the reduction of service outages as a result of failed changes. As well as reinforcing that we are protecting the business while making changes to their environments.

Challenge 2 - Ensuring all changes are recorded
As everyone knows there is always a path of least resistance and the natural tendencies are to go that route. The trick here is to ensure that your change process is such that it covers off all requirements to successfully implementing a change, but that it also doesn’t impede the implementers with bottlenecks. Sub issue here is that depending on who you ask, will depend on what the bottlenecks really are. This transitions nicely into….

Challenge 3 – Who does (and should do) what?
At a practitioners forum I went to a while back I recall that one of the challenges an organization had revolved around the approval process for a legacy application. As it turned out in some cases it was not unheard of to have several dozen approvals. In reality many of these approvals were nested within the same functional group and were beyond redundant but this was the way it was set up. When they asked the business they didn’t even know why, “It was like this before I got here” is how they replied. This would be a good opportunity to go back to them and illiterates the value of streamlining this so that the bottlenecks could be reduced.

Challenge 4 – Organizational Scope
Depending on your organization you may, or may not, leverage your change process across the entire organization. This really depends on the maturity and culture of you organization. In many places they stick to the boundaries of IT with reluctance to move beyond its borders. To do that you really need to be able to articulate how the process has enabled the success of IT and where it can be beneficial to the business



Follow us on Twitter @ryanrogilvie


Tuesday, 12 March 2013

Reporting on Service Management Metrics – “You can’t handle the truth!”

Recently a colleague of mine was (who shall remain anonymous) called me up and wanted to ‘pick my brain’ on a few things. They indicated that since they recently started their initial ITSM processes six months ago they (senior leadership) were now in a position to see the fruits of their labour from a metrics standpoint. They currently are using a popular ITSM product which has good reporting capabilities, and have a team which performs the Service Request, Incident, Problem, and Change Management processes. To give even further context they use ‘Incident records’ to track all requests and Incidents and manage them through their priorities. Priority 1 being critical and 5 as a request etc.
So far it sounded as though they had a pretty good start on things, and this is where the question came in.
“While we planned everything out, some of the metrics might not reflect what work is really going on” I was told. They proceeded to inform me that when they went to their VP of IT with the preliminary stats that there was a high degree of confusion on their face. “This can’t be right”, they said abruptly, “We don’t have this many high priority incidents and that they don’t last this long”. “Your reporting tool must be spitting out bad data. Better check it again before I need to send this out to senior leadership.”
While my friend was telling me this I couldn’t help think of that part in A Few Good Men where Jack Nicholson says “you can’t handle the truth”
The question I then posed back to my friend was “What are you trying to gain from your metrics?” In reality we are all reporting on data with the intention that when we review it we are going to identify areas of improvement. At the very least when the senior leadership in this case reviews that numbers it should be a place to start a discussion for improvement possibilities. Despite what the intentions were (or believed to be) when they started with Service Management, they have already grown to a point where they see some room for improvement. In this case they identified that the way that they interact with the business and prioritization of their ‘incidents’ is the first place they need to tweak. My friend went on to mention that the services that they said were critical services maybe are not and as a result should also not impact the way the priority is calculated within the tool. This may also need to be revisited.
My suggestion was to deliver the metrics with a report which illistrates the areas where these numbers may not be an actual representation of what the business wants to accomplish. There really nothing wrong with what we captured as far as information goes, it simply lends itself to telling us where we need to make some adjustments. Gaining this alignment early on will also allow them to allocate the right resources to truly critical issues. Otherwise it would be easy to blame the tool with a miscalculation of the activities going on.

While it would appear that there is no way to produce complete stats the way that was originally envisioned, it will be better to fine tune these things before it further impacts other ITSM processes which rely on the outputs from Incident and Request Fulfilment, as this will ultimately impact their numbers as well. My friend will keep me updated i'm sure, but admits they won’t be able to get that Jack Nicholson bit out of their head when they review it with the VP.


Follow us on Twitter @ryanrogilvie


 

Thursday, 7 March 2013

Knowledge Management - Knowledge is Power

Knowledge is power as the old saying goes. Let’s consider for a moment that we are in a position where there is no formalized knowledge management policy in our organization and to complicate matters further we are in a fast moving ever changing environment…. Ok, so that may apply to most of us. What we may not realize when we are busy is that each day there is a component of duplicated work, lengthened decision making as a result of not having a formal knowledge base and readily available information.
The other concern is that we have all worked (or currently work) in an environment where there is the “go to” person who has all the info stored in their head. The risk here is that all the information is stored in the one person’s mind. The intention here is to ensure that the data dump is completed from said persons brain to a repository somewhere. Unfortunately more often than not when this doesn’t happen and this person leaves we wished we had ensured the information was saved and a scramble to re-discover information begins

So what do we need to do this for?
Even though we understand that this is a best practice we still require buy in from our stakeholders to not only get this off the ground, but to keep this initiative going. Like a CMS, this may be happening in some capacity now but we want to formalize this in a way which is sustainable for the long haul. As with any other process improvement the best place to start is to evaluate our current state. Some of key things to address include:

·         What information is currently captured,

·         how it is recorded, and

·         where it is stored
This will give us a better idea of what information we have (or don’t have) and the best way to move forward. Define your scope. This can’t be stressed enough.

Challenges to getting this underway
Like anything worth doing there are going to be some challenges along the way. After reviewing where we are currently we will need to likely address some of the following questions:

·         Where do we plan to keep documentation – do we have existing tools or require something else?

·         processes around keeping it up to date – how do we not let this fall off the rails

·         WIIFM and what will this cost

In addition to addressing these questions we will also need to market reasons to have knowledge management to the people who will help make this happen. Some of the benefits include:
·         Having available knowledge for afterhours support

·         Self-service components allow end users to quickly find answers to support questions

·         Improves learning curve of the users

·         Reduces call durations and increases first level resolution

It’s important to translate this information into what really counts:
·         improves customer service and
·         cost savings.
Once you have this in place it will be important for the process owner and key stakeholders to periodically review the status of your Knowledge Management and take the necessary steps to keep it up to date and effective
Follow us on Twitter @ryanrogilvie

Tuesday, 5 March 2013

To Tweet or not to Tweet? Why Social IT for Service Management - Part 2




Where do we begin? First we need to identify what the current level of maturity our social IT is. Then we can determine how the culture of your organization will handle any changes to it. There will definitely be differences based on the average demographic of the employees, the size of your organization, as well as the industry you are working in.
The next step will be to see if there is a current social media policy of any kind, and understand what it is about. If we do not have one we should get one established, even in its simplest form. We will need to differentiate how Social media is used outside our organization as well as internally. Depending on where you are Marketing may have a defined and regularly executed an external social media strategy, while your internal Social IT may not exist or may be limited.
We have to decide what we plan to get out of your Social IT. In keeping things simple we might want a vehicle to share knowledge, known issues, how-to’s and things of that nature. This may allow the Service Desk to deal with more complex issues and incidents. Keep in mind “you can only manage what you measure”.  Before we communicate to your stakeholders you want to assure them that there is some gain or ROI on what we are doing. Even if the Social IT we are implementing is simply to knowledge share, there is going to be a gain in some aspect. As a result of this enhancement the number of requests for information to the service desk may decrease. This statistic can be further quantified by a customer survey which indicates that the level of service has improved. From a dollars and cents aspect we don’t have someone responding to the same questions day after day which reflect some cost savings. Our customers are happier and so is your budget
Now that we have asked ourselves why, who and how, we want to ensure that our process is in place and understood so we can determine when we will turn on our Social IT. Once everything is lined up we can return to the stakeholders with the plan which should include the communication plan for your target audience. This will outline the policy for use as well as what we are trying to achieve. Our social IT can quickly take a life of its own so it’s important to balance the managing the information while not stifling activity to share information. We need to ensure we have a way to manage any feedback as well as ensuring that we review the state of things regularly to tweak where necessary.
Keeping things simple, and reviewing regularly our progress and maturity in the program will ensure continued success

Follow us on Twitter @ryanrogilvie