Thursday, 30 October 2014

Not Doing Proper Post Incident Reviews Could Haunt You

From a service delivery perspective a thing which is more frightening than having a major outage is the potential that the issue could happen again if we don’t do proper post incident reviews after service is restored. 

Call it whatever you want to; severity one, priority one or major incident, when service is adversely impacted, you need to make sure that it is restored as quickly as possible. while you are doing this however, it is important to make sure that you are collecting all the information you need to ensure you can learn from this experience to assist in the future prevention of this type of incident.

Having worked on more critical incidents than I care to remember, there is a common flow on how they operate. In the initial stage there is a sense of “is this an issue?” people are escalating information that may or may not relate to the current situation. While it may seem like a major issue it might be tougher to separate the real deal from some side effects.

The second stage is the collecting data and discovery phase where we are starting to get a sense that the issue is real and is impacting a wide majority of people. We are able to confirm through various escalation points this is indeed happening and we have started (hopefully) to gather some support resources to assist.

The third stage is what I like to call “Let’s fix this NOW”. The drivers for this may be the criticality of the service in question or an agreement of some type. It might also be driven by someone (usually at the top) doing the gargoyle over the incident command center.

The final stage is where we have resolved the incident but are looking for confirmation that it is truly restored, or the I think we’re good stage. It is in this stage where we should schedule a post incident review. It is also important at this time while the issue is being verified as resolved that the incident record is as current as possible. This way when we do the review we have all the information we can to ensure we can make the most of this.

Here is the challenge, in a culture which celebrates firefighters we want to make sure we do go back and do the post incident review in the first place. It is very easy to say we will and then another crisis appears and it gets postponed indefinitely.

The next challenge is to make sure that we have enough information to see what went well and not so well during the investigation. Did we have the right resources, what areas did we check. Could improvements be made on the investigation and diagnosis end for next time should it arise?

If what we did to correct the issue was a system change (I am sure an emergency change was recorded) than is there anything we need to adjust to other systems to ensure they are stable. If this incident was the result of a change what can we learn from that.

Remember, the review should have all parties who were involved in the incident as well as keeping people who are related to the support of the service equally as informed. Just because the application delivery team was not part of the restoration process does not mean they do not need to be informed on a service they also support.

The post incident review should also be kept as a knowledge record which is accessible to all appropriate stakeholders. Any action items which were identified in the review should have a timeframe and be validated as completed. There isn’t much point on reviewing if you aren’t going to follow up on them.

To ensure we are able to provide service we must be sure that we not only have a way to restore issues should they occur but have an equally good method of ensuring issues don’t happen a second time.

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


Monday, 27 October 2014

Wait, internal customer service has to be good too?

Your business has wants and needs. How you, as a service provider, satisfy their appetites will indicate how successful you are. In the not so distant past customers had to deal with lengthy wait times on phone support lines and long physical queues for assistance. Over time technology has enabled us to improve on the delivery of service to customers so why hasn’t the translation been made from the shared services to the business. 

Question - How is your internal organization serving your business?

Think about an everyday situation. If your local shop stopped carrying the items you needed and were available elsewhere it is highly likely that you would switch shops, even if only to get the one or two items. The trick is that these other service providers understand your businesses needs even if you don’t. they look for ways to upsell and bundle to not only get your business to keep coming back to them but to entice them that they have other products and services for sale. While your business will still come to you for the staple items they may be shopping elsewhere for specialties and you may not even realize it. It is possible that they are looking right now, and in time your services may not be able to match up to your competition

Another challenge is that we (and by that I mean you and I) find it have a different expectation of the services we receive when we are at work as compared to outside the office. If we were to get a less than satisfactory turnaround on a request, even though it was promised to be completed quicker we might be more likely to shrug our shoulders. However if the same situation happened to us personally we would not tolerate it. Think about when you started with a new company you likely signed off on an onboard package of some type including the amount of compensation, possible health care coverage, weeks of holidays but did you see a page which said you should have lowered service expectations as part of the company. We need to hold ourselves to a higher standard with regards to service delivery to our business as they may not tolerate us for long

While these examples really apply to any shared service provider I choose to pick on IT as this is where I spend my time as an employee. Trust me this is not an IT issue, it is an internal service provider issue and I have experienced it first hand while attempting to get service from other shared services.

To turn this around start thinking of service delivery like your business does. For them to succeed your business needs to be in a position to be scalable and adjust to the economic climate in which it exists. If they cannot meet customer needs and expectations someone else will and your business will be in trouble.

IT service delivery needs the same ability to be agile and scalable to ensure they can provide the services the business needs to achieve its goals.

Start by working with the business to identify the services they are using right now. Which ones are Critical, secondary or tertiary. Doing this will give you a sense of scope for your ongoing improvements.  Keep the scope simple and target a few key areas for improvement. Ensure that these improvements are measurable so that you can share the success you are having with stakeholders in a quantifiable way. Communicate this information appropriately with stakeholders in a way that makes sense to them to keep the momentum going.

There are many ways you can leverage people, process and technology to improve the delivery of service to your business but remember you need to work with your business if you are going to make any improvements which will be lasting and improve their ability to achieve.

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

Thursday, 23 October 2014

Is Your IT a Wallflower?

I recently was speaking with an IT leader who was saying that she was having challenges getting together with her business counterparts.

“They must just be really busy” she sighed.
“Are all of them are busy? Must be a huge initiative underway, is it annual budget review time or something? I asked.
“Well we only have one contact in the business who we typically deal with, and they just don’t have the time.” she replied

As she mentioned only one business contact I could feel myself fading into a flashback when I would go to junior high school dances, not entirely sure how it did that, but it did. As I stood there in a daze for a second I soon realized that this situation somewhat reminded me of asking a girl to dance. Follow me here for a bit, Think back, guys and girls would be in their own groups and as the music started there would be a hurried pace to get a dance partner much like a reverse musical chairs. Inevitably the remaining people would look around realizing that time had run out.  

The stragglers would start to justify their lack of partner by saying to themselves something like; “that girl I was going to ask is already with someone else, guess I will stand here until she’s free and ask her next time. Meanwhile, on the other side of the dimly lit room a similar group of girls stand wondering why the younger version of me didn’t come over. They would rationalize it as maybe he didn’t see me and they might wait for me to get a clue. Newsflash – teenage boys don’t get the clue!

Despite the perhaps simplistic comparison there are striking similarities with the business and IT interaction to a degree. If IT is waiting for the business to make the first move and ask them to dance they could be standing at the side with your hands in your pocket until it’s too late. In some cases when the business feels that IT is out of touch they may choose to have more than a few dances with another partner and decide to get their services from an alternate provider.

Much like in this junior high school dance example, you should reach out to other people who you might not have otherwise asked. In some cases finding another business contact will prompt your current contacts to take notice and get more engaged. Having a few different perspectives, through a multitude of ‘dance partners’ on how your business consumes services will give you a better sense of the big picture. Initiating these conversations will start to position IT in a way in which will allow you to identify additional commonalities and subtle differences which may impact the way you deliver service, as well as the way you support services

The key, I explained to my colleague, was that their discussion with the business has to continue and to grow beyond one person. In the beginning it might be slow, so don’t get discouraged. The result in the long run is that you will have improved the relationship you have with your business and will be less likely to standing wondering why you have no one to dance with.

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

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



Thursday, 16 October 2014

Problem Management – The value in not knowing

Having worked as a problem management analyst I always understood that there was a point where you may dig for root cause and still come up with seemingly nothing. It was because of this that I always like the quote by the fictional character Mr. Spock “Once you have eliminated the impossible, whatever remains however improbable, must be the truth.” That’s an interesting thought and I will explain how it applies to problem.

One of the challenges with working with problems is that for the most part IT may have a somewhat backwards perception on the process which searches for root cause to eliminate incidents. In many cases (but not always) IT values the work in which incident does to correct issues. We have heard this all before, so I won’t beat that drum, at least not today. The trouble is that there may be very little emphasis on what goes on behind the scenes to permanently eradicate these incidents from happening in the first place.

Some problem managers would beat themselves up as they seem to get really close to figuring it out, but then seem to come up short. While others become frustrated when they chase a wild goose so to speak and end up not solving the problem either. So what’s a good problem manager to do?

I look at it like this; I may not know what the cause of the problem is, but I know what it isn't and that is important. This might make me a “glass is half full” kind of practitioner.

The important thing I try to do is not keep these findings locked away in a problem drawer somewhere. There was in some cases considerable effort spent to find this information, but since no results were realized it looks as though nothing was accomplished which is not the case. That is why so often when management looks back on problem it seems as though loads of effort is spent with little gain.

During the investigation of a problem I try to not only track the findings in the problem record but share information with teams as there may be unrealized value to them. Your organization may have regular problem meetings in which the information is shared (if you don’t you may want to consider starting). A key thing to remember when you are having these review, you may have more interest in the investigation than the audience in which you are sharing with. I once met a guy who said his problem reviews we held monthly over a two hour session. There were quite a few yawns and eventually less turn out over the course of time.

The key is to have a format and review what is important to not only the meeting participants but your business outcomes as well. There’s a pretty good chance that if your business is impacted your meeting will have more merit. Another consideration is you likely have problems which have a low priority and may not require review, so mention that they exist but only address them as a side bar if someone requires it.

The list of review items could look like this:
·         Problem description
·         Impact to business
·         Related incidents since last discussion (volume/durations)
·         Planned changes
·         Any findings even if they produced no results.

It should include a representative from a breadth of teams from infrastructure, application support, service management, and where applicable you can include business relationship managers or service delivery teams.

This brief review will allow participants to provide input even if your current problem analysis has hit a dead end. This discussion point may also shed some light on other areas or even other problems teams are facing which may relate to your other investigations.

The key is to keep it brief will allow the people attending to get on with their day and spend more time helping to improve service delivery rather than spending time reviewing what isn’t working.

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





Monday, 13 October 2014

VIP Queues for Service Requests – What’s the Value?

While those of us here in Canada are still feeling drowsy from the effects of the tryptophan from turkey I began to wonder if the value of having a VIP queue is like saving a certain bit of turkey for your uncle.

It is likely that if you ask the VIP they may have mixed reviews on whether they should in fact be on the list. On the other hand they may not even realize that they are on a list as their executive assistant handles all things great and small.

First of all, what makes up a VIP? It could be a fairly subjective thing. It is possible that your team determines anything above a certain title qualifies. The challenge I pose is are their requests more important than that of the staff which are in the business performing daily activities. In some cases you may have a senior leader who would rather not be on an executive support list and would rather see the support teams focus on those things which impact the business

So to ask again what makes a VIP? Is it possible to make it service centric. If we were able to identify services which were of a VIP nature perhaps we could have those who work with those services defined as VIP as well.

The challenge is that there needs to be a way to manage this list as well as the expectations behind it. If you have a system which is able to tap into people attributes and identify if they have a particular role whether VP or executive assistant you may be able to keep on top of it. However if you do not there may be more effort spent on keeping the VIP queue accurate than if you just focused on providing service equally across the board.

Another consideration is the management of the support as it must be consistent throughout IT. Just because the service desk is able to identify a VIP and escalate it to a specific team does not mean that they will action that request first. It must be understood on what is the expectation for VIP service much like an internal SLA in essence. If teams are expected to drop everything to get this request handled it could impact service for the general staff down the line. In some cases if desk side support is required in person they may have to re-arrange their day to account for this need at the last minute which could adversely affect the delivery of service and actually increase resolution rates for the majority of people because of a small group of VIP’s

The real question you need to address:

Are the “VIP’s” asking to have this implemented or are we assuming that they need/want it. At the end of the day we are accountable to ensuring exceptional service delivery. Does this satisfy that?

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

Thursday, 9 October 2014

First Call Resolution Basics

After the last post, Request Fulfilment and the Stop Button, I received some feedback and more importantly questions around first call resolution. The theme was how to track it better.

Depending on the system that you use for tracking requests you may have a very easy way to calculate this. However from the people I connected with after the post they either did not have a simple way in their current system or, when they set up their current system they inadvertently made it more complicated to track.

But let’s take this discussion back a bit to see where this all comes from. We have all heard from the top that we want to improve on our first call resolution but why?

The statistical answer is that we are able to quantify the number of requests which were handled by the service desk, but what other impacts are there. I will give you my favorite three:

1.     It’s cost effective. Let’s face it; it always comes back to the cost of service support. For example, if 55% of the requests we get in are resolved at the service desk level the other 45% are hitting 2 or more teams, which you guessed it comes at a price. More teams equals higher price tag, do we need to have all these teams looking at this? Further investigation to this may indicate that we have escalation issues which impact the cost if it goes to the wrong team by mistake.

2.     Making customers happy. Think about your own experiences if you are able to call, email or chat and get a resolution right away you are going to be far more satisfied that if you have to send something in that may be reviewed for an unknown period of time.

3.     Happy customers are loyal customers. If you are able to better satisfy your business, they are less likely to look for ways around you with shadow IT or other vendors.

Ok, so we know why we want to do it but how do we better manage the reporting if our system is less than cooperative. Since there are many nuances to everyone’s system the best way is to be a master of the data that comes in which constitutes the FCR numbers and those which do not. The trick is to decide what you want to know so you can engineer the request form to produce results. My motto – simple is best.

In the beginning you may just want to know the volume of FCR and how they were escalated. The easiest answer is that we have a checkbox or a flag of some sort to indicate that the request was handled in the initial call. The next challenge is to differentiate between phone calls, email and any other avenue where requests may be initiated. There may be a drop down for this with a few choices. Remember we want to keep it simple so that we can break up the FCR which were resolved on the phone vs the FCR which was handled by chat. Doing this will allow us to better tailor improvement strategies and automation down the road (that’s another post)

When we do something like this we need to ensure that the teams who will be completing the request forms understand why we need to ensure accuracy. They also need to understand that the goal is to ultimately help them improve their workload by understanding what comes in each day.

To ensure that we remain as accurate as possible there also needs to be a level of audit. This may be done by the service desk lead or manager but there should be some takeaways from the reviews that are done on the information. Sharing with the team what was done well and not so well in an anonymous way will allow your team to improve the information which is captured.

Overall the goal of this is to improve the satisfaction of customers so we should also accompany these stats with some customer follow up to ensure that not only did we resolve the request in the initial contact but that we did it in a satisfactory way.

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

Monday, 6 October 2014

Request Fulfillment and the Stop Button

Depending on the way you manage the teams which support your services and the systems you have available to track and report on that performance you may have varying ways in which you review the time spent on providing service support.

There are basically two unescapable truths when evaluating team performance.
          1.     Your team wants to provide good service and
          2.     They want to look good doing it. (Not in fashion but in performance)

When requests come into the service desk there may be an efficient tracking stopwatch around the support team resolving the request themselves. Request comes in, is worked on and closed. However what happens when you start to have more than one group or several groups and the ability to measure components of work gets complicated?

For example:
For a particular request to be completed the request needs to have some tasks completed by the service desk and then the request is sent off to an application support team for completion. The IT support team operates Monday to Friday 9 to 5

Let’s suppose that this request came in towards the end of the business day (4pm) and let’s assume that the first part takes 1 hour. The service desk completes their piece and the request is sent off to the next team. Of course everyone is going home for the day so the request is in the application support queue.  The first thing the next morning the application team promptly completes the rest for the request within the first hour. Once this is completed the application support team resolves the request.

Theres a few ways to look at this:
·         That the request physically took two hours
·         From a customer perspective the request took from 4pm until 10am the next morning – 18 hours
·         That potentially from a reporting perspective the only team which gets credit for this request is the application support team and they either get the 2 hours timing or 18 hours.

The challenge with this is to identify areas for improvement within your queue management. It may look as though the service desk whips through tickets as they are only working on and resolving their own tickets. There may be no consideration (depending on your ticketing system) to review the multi group components. On top of that there are teams who are frustrated wishing for a “stop button” to only show what work that are accountable for.

I understand that there are many companies who are leveraging systems which account for this. However there are still others who are not. Taking a good look at how you manage your delivery of service through queue management will allow you to target areas within the escalation which may need to be fine-tuned.

At the end of the day it is the customer experience which we are looking to address. So whatever internal workarounds we need to employ to make sure we can target the queue and escalation process for improvements, we should strongly consider them.

I realize that this post is the tip of the iceberg and that I didn’t touch on SLA’s or first call resolution and a few other items but I look forward to diving into those in the next few posts. There are many areas, not just IT, who leverage services in this way. Feel free to connect with me and let me know what has worked well and where you are having some challenges.

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

Thursday, 2 October 2014

Understanding Services - it’s not really magic

One of the challenges with operating a service desk is perception. From a customer perspective it can be a bit of a black hole, requests go in and some service is provided. During my tenure on a service desk I was at a corporate function where I was sat next to someone from the business. I introduced myself and when they asked what I did I told them that I worked on the service desk. Their eyes widened, and they said, “I always wanted to know how you managed all the work that came in, does it depend on job title or what?” I felt a bit like a magician not wanting to give up all the secrets to the apparent ITSM magic while still explaining them that there was some method to the madness. It was when I was formulating my response that I thought to myself do we do this the best way possible? It was at that time a waiter came along with beverages and my curious business person moved on to other topics with someone else.

The next day at work I had that question still in my mind. I asked the same question to the service desk team I was working with. The answer for our organization was that we worked requests first in first out (FIFO), unless there was a major incident. But was this the best method? The challenge to this was that in some cases people would change their email subject lines to read “CRITICAL” or have a heap of asterisks or exclamation marks. We know that the answer is yes

However if we were in a position to manage the queue by order of operations based on service perhaps the more time constrained requests would get done in a more timely manner and ones that could wait would.

To do this however you have to have a good understanding of the service. You also have to have a good grasp on the impact that requests or incidents have on the service. For example if our ticketing system for requests was geared to have a default priority of ‘medium’ and no one altered it the queue, all requests would all be equal priority in essence, thus FIFO . But if we based our triage on service we may be better able to filter items based on services and business requirements.

Of course there is always a risk here. In this case we not only have to know what the service does and how it impacts the ability for your business to function, but we have to need a process to review that the service is current, that its status reflects business need and that how we provide service is meeting the expectations of those we provide it to. Keeping current is as much heavy lifting as implementing.

This is where we need to ensure that we as a service provider review how well we are doing. While the service desk is the first point of contact, the rest of the support functions also have a vested interest in the way we provide service.

The benefits of really understanding the service will better position IT to quantify what it costs to provide that service. This valuable metric will allow us to work with the business to ensure we have the right resources, whether people or otherwise to continue to provide excellent service delivery and improve on that over the course of time.

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