Thursday, 31 July 2014

Holy Shark! It’s the ITSMNADO

Call them what you want; best practice, framework or a BOK, there are several ways in which Service Management can enable the business to achieve its business goals. But with such abundance how do you know which one to use. Of course there are the most popular ones such as ITIL, COBIT and ISO, but what about the ones that aren’t as well known. Despite poking fun at the movie Sharknado where the sharks were cut down with a chainsaw, Van Haren publishing has shown us the pen is mightier than the sword and put together a great synopsis of the more common ones calledGlobal Standards and Publicationswhich is free for download.
As I went through the list (there may be others that aren’t here) I noticed that each of the reviews had a consistent outline including some background, target audience, the benefits and constraints of each of the frameworks. The nice thing about this format was that I was able to think about ways in which I could augment parts of service delivery in my organization with a different approach fro a perspective which is new.
In my opinion implementing practices ‘by the book’ was never really the intention of how these were supposed to be utilized. You really should be looking at your organization in a way where you can decide what is fit for purpose. Taking pieces from each of these guidelines and applying them to your business where it makes sense in an effort to achieve your business outcomes. No two businesses are the same and to that end managing the services which support them should be looked at with an open mind to how best to support them. Keep in mind that supporting a financial institutions banking service may require different guidelines and governance than an online web application may have.
I believe that marrying a few of these together can work to further your businesses goals where only one may appear to limit you in some way. After all at the end of the day we are all working to improve service delivery.
I would really like to hear what you think about this topic and what ‘framework(s)’ or whatever you call it you use and what makes it a success. Feel free to connect with me on Twitter @ryanrogilvie

Monday, 28 July 2014

How Does IT Impact Effective Service Delivery?


There are a variety of opinions and frankly literature on why we (IT) seem to hit the wall when it comes to taking service delivery to the next level. What is the barrier that IT faces? As the saying goes you can’t see the forest for the trees – for some reason IT just can’t seem to see past the technical fog to realize we are supporting services.
 
The biggest challenge - look in the mirror

In many cases IT does not fully understand the service in which they are attempting to support. That’s right, I said it, IT is getting in their own way to improving service delivery. This will remain a fact despite whatever technical wonders are available to them, so long as your IT organization continues to do things as they have in the past.

Think about this for a moment, what happens when you support teams do not know how to escalate support calls? There will inevitably be a delay in response because your requests or incidents are going to the wrong groups. How can this happen? It is because we don’t fully understand what is require for the service to be supported effectively..

Another common problem is that assumptions are made. A good example of this is when requests or incidents are marked as resolved. When we believe that an issue is corrected we may close the request or incident and move on to the next record in the queue. In some cases there may be an automated mechanism which prompts the customer to “click here” if not satisfied. While there is consideration for the customer feedback you need to start thinking to yourself “does this response get handled in a meaningful way?” IT may need to have an enhanced connection point with the customer base to ensure that the work completed was satisfactory. Not to say that we should call every requestor and see how they are doing, but have a method in place for dialog to occur. To start with a random check of these requests or incident is a good start. You may be doing this now to address technical completeness of records but reviewing them on customer satisfaction has its own merit. Knowing where we stand from a service delivery perspective, both from the challenges and successes will allow us to continue to streamline the way we work.

My favorite misstep, which I mention regularly, are the “fixed by magic” issues. We have all had these types of issues which seem to just “go away” however we need to ensure that these are also tracked and categorized in a way which we can take a closer look at them. While even the business may suggest that they are not a big issue they have a tendency of adding up and impacting the business at the worst possible time when we least expect it. Knowing the issue exists allows us to look at it closer and again speak with the business that we understand this pain point and work with them to address it. It may be something that we are not in a position to fix but working with your business to determine what is appropriate will take away the assumptions IT has been known to make in the past.

There are many more examples of IT being the limitation to their own improvement initiatives. Feel free to share yours with me here or connect with me on Twitter @ryanrogilvie

Monday, 21 July 2014

SLA’s and CSI – A Two Way Street

The other day during a #itsmbig4 twitter chat the subject of SLA’s as they relate to CSI came up, which got me to think about this topic a little further.

The first question I found myself asking “are SLA’s for the most part provided by IT?” It might be more common than not to hear IT tell the business, “We will provide service uptime of 99% or some degree of 9’s.” In some cases there may be no negotiation/agreement at all. IT may on some level decide that the business needs a certain degree of service level and based on the ability for IT to support the service, a service level is generated. This provision may occur whether the business has signed off on it or not, in fact they may not even be aware that such a service level even exists. Being in a position to even have an agreement requires that there is more than one party present. This discussion point is a two way street in which you need business input. I already know what you are going to say. “If you ask the business they will say that they need all services up all the time.” Again this is where the dialog and agreement part come into place which we will touch on down below.
So where does this tie in to CSI? As the name suggests we are always looking to improve service but in order to start doing this effectively we need to discuss where we are today with all our stakeholders in IT and the business. To simplify this discussion on some level let’s look at this from 3 basic stages in SLA maturity; No formal SLA’s, SLA’s established in IT and formal SLA’s established with the business.

No formal SLA’s
In this stage of the game IT has services which they are supporting, likely with a best effort mentality. The level of service to your business may be considered adhoc as there is no direction on how best to provide support for a multitude of services. From a CSI perspective you really need to understand which service(s) is critical to the business in an effort to prioritize them from a support perspective. Just because there is no formal SLA established, doesn’t mean that there isn’t one in existence on some level. Your support teams may just ‘know’ that the corporate website is a critical service and treat it as such. I would imagine that the business has some expectation either way that the service is going to be available for them to utilize. Even if you initially have no agreements, building a framework of dialog will allow you to improve delivery to service through an understanding of what the business needs are.

SLA’s established within IT
The challenge here is that the SLA is an IT assumption on what they believe the business requires. There may be an expectation from IT that all services require a standard uptime of 99% for example. This may be valid to a degree however the challenge is that we still are making assumptions on what the business needs without engaging them directly. Being able to do that will allow IT to adjust their OLAs to ensure effective service delivery.

Once you do that you can better position yourself looking at what support to services will ultimately cost your IT organization, and ultimately the business. Remember earlier when I mentioned that the business wants 100% uptime. Positioning yourself to understand the cost of service will allow you to communicate what 100% would cost.

Formal SLA’s established with the business
In some cases we may have formal SLA’s set up with our business. The challenge here is that we ensure not only that we manage these in a balanced way but that they are constantly reviewed to remain valid over time. A balance support means that it can become very easy to bulk up on your incident management to ensure that issues are resolved as quickly as possible but make sure that you are looking at the cause of these issues in the first place. As I have mentioned before issues which repeat themselves can have a negative impact to the business even if they seem small and insignificant. Ten repeat issues which last 10 minutes are the same as a major outage which lasts 100 minutes. When you have a strong understanding of the service and are supporting it in an effective way you will be better able to agree to terms of service with comfort that you can cover what you agree to. All too often we set an arbitrary target for some level of 99% and we tend to coast once we maintain that level. The CSI question should ask what we are doing to continually improve our service delivery. We should think about reviewing the SLA’s with the business on a regular timeframe as their requirements of the service may change.  


The overall theme is to stop assumptions of what the business needs. Begin a regular discussion with them on the delivery of their services so that continual improvements can be made. As time goes on review where service delivery shortcomings are and deal with them in a way which is not necessarily incident focused but also drives out repeat issues, perhaps through problems. At the end of the day regularly discussing what is working well with your business will enable you to continuously improve your service delivery.

Please feel free to comment or connect with me on Twitter @ryanrogilvie

Monday, 14 July 2014

Is the Customer Always Right?


Over the weekend I was in a line at a chain restaurant where a customer had pushed his way into the front of the line and began ranting about something wrong with his order, and he demanded to see the manager immediately. While I tried to ignore him without success I heard him say at one point “The customer is always right you know!”

This made me think about it for a moment. While there may have been an issue with his order all resources were being expended to correct his issue while other customers waited. When I finally got to the front to order the person behind the cash register said. “He forgot to order an item and so it wasn’t given to him.” This made me think, is the customer always right?

If you were to ask a customer they might think so… after all this motto has been around for awhile and is engrained in the way we expect service to be delivered. The premise is that through the delivery of a particular service(s) that customer satisfaction is the primary objective. For some this may imply that we do whatever is needed to achieve this objective. You may have also heard the phrase customer is king.

The challenge is that people, much like kings, can be wrong from time to time. What is important is how the interaction is handled by the service provider.

The flaw in this example, in my opinion, is giving the customer whatever they want. Whether you believe they are right or not at the end of the day the way in which you manage this interaction will ultimately determine the baseline of how you deliver service. Rather than simply giving them whatever they wanted, asking them what they believe was expected and what was wrong may have more value long term. At the very least soliciting this information will allow you as a service provider the opportunity to minimize this type of challenge going forward. In this example if the order could have been verified beforehand, perhaps this item wouldn’t have been missed at all. The risk is that the delivery of service to the other customers was delayed as a result, while you have appeased one customer you may have inadvertently put off other customers.

Determining a strategy for this interaction needs to be identified so that if (and when) this sort of issue arises your staff who deal directly with customers will be able to address each escalation in a consistent way. Don’t forget they are also feeling frustrated from bad service delivery, since they are on the front lines. Documenting a list of customer impacting issues will allow you to improve service to all customers, not just the ones which are experiencing issues.

This applies to the delivery of IT services to our business in the same way and is why service management is important. Being able to not only manage, but continuously review and improve the customer experience will allow you to enable your business to reach their goals.

I would love to hear some feedback on this topic.



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



Monday, 7 July 2014

What percentage of ‘suckage’ does your #ITSM processes have?

I was speaking with a colleague the other day and she was expressing her frustration over some issues she had with their change management process.  

“Oh, what’s wrong with it?” I asked
She replied “That the process REALLY sucks.”
Seeing the open door to go through I asked her “What percentage of suckage are we talking about here, like 40 percent?”

Her frustration was replaced with a smirk but went on to say that realistically they are having some issues with application performance, which always seems to go back to changes gone wrong. She totally gets that since a large majority of incidents result from changes. She continued on to mention that the issues seem much worse as of late.

The first thing that I asked her was to take me back to the time when the process seemed to suck less. She said that it was about a year ago, and didn’t seem to get bad as a result of one thing. My next question was for her to explain what factors from that time until now may have contributed to the process breakdown. My suggestion was that she might need to go over her KPI’s and then let me know what she saw. I was specifically interested in:

·         The volume of changes
·         The number of expedited changes (if any)
·         The rate of change success vs. changes which were not successful

I also wanted for her to think about the way in which the IT culture may have changed in that time frame. Has there been any change in the way in which IT is working with the business in the past year as well.

A few days later I checked in on my colleague who looked far more relaxed than the past time I saw her, but I could tell that most of the challenges she was facing started to make sense to her already.

She told me that after she took a step back with an objectionable view of the situation several things were clear.

1.     While there was an increase in the volume of changes overall, the applications which saw the most issues had the highest percentage of expedited changes
2.     That the rate of success seemed to remain the same despite an increase in reported issues
3.     That the business units and IT have been on a less collaborative space since some internal org changes took place.

She continued to outline that one of the new directors in application development was previously at an organization which had a far more agile approach to deployments. This was apparently why there was an increase in smaller expedited changes.

My suggestion was to firstly ensure that the governance of the process was intact. For the most part it sounded as though with the exception of a few applications that the process was doing as it was meant to.

Quite often the trouble is that aside from the business saying that the applications were falling apart there was no linkage (related incidents) to these changes which were causing the issues. Because of this lack of relationship we may have simply overlooked our own issues. This is why not only pulling but analyzing reports is key. The incident and change management teams should be working closer together to identify these issues. Once they have some solid analysis they can take their findings and review them within IT. It may turn out teams may not be “ready” for agile delivery in this manner just yet. Just because some organizations are doing it doesn’t mean all are capable without some guidance and practice.

Lastly making sure that you go back to your fundamentals of service delivery and really talking with your business about what their needs are regularly. Don’t forget business needs change. If they really need more agile delivery then that should be part of our deployment strategy. Otherwise we need to reassure them that we are working to ensure that services are available to allow them to achieve their goals.

This gave my colleague something to think about. She was going to review this with her management team to start to streamline activities.

Follow me on Twitter@ryanrogilvie

Wednesday, 2 July 2014

Translating IT and Business Speak

Some years ago I took a break from the workforce to travel about in Europe, a sort of sabbatical. Once on the continent it became clear the level of diversity amongst cultures and languages were beyond even my expectations. In my mind I understood the importance of being able to speak the local language as much as possible even if I was only going to be there for a short time. My rationale was that if I could ask for the essentials including lodgings, food and a pint, I would be able to get by on charm for everything else.

It was on a train from Paris to Lyon that I came across Giles, a retired French teacher who spoke excellent English. Having always admired the ability to converse in multiple languages I sat with him. He explained to me it was in my best interest to continue to exercise my French skills (even though I thought they were mediocre at best) while I was in France. His explanation was simple “You may not be fluent and may stumble a bit, but you will find that your interactions with people in your time here will be more enjoyable.”

This is also true of the IT and business interactions. While we both ultimately have the same goals quite often we may be speaking different languages – Technical and Business. An important part of this dialog is to understand the gap in communication between the two. This only really can happen when we get together and not only discuss but really listen to and understand what the other is saying.

You may have the Business Relationship Manager who facilitates this process quite nicely. The BRM may perform many activities but are able to interact as a liaison between the business and IT with regards to achieving outcomes. Until your organization has someone in this capacity you may have to take the initiative and start this on your own.

Getting Started

You might ask “Where do I start?” In the past I had decided to meet and interact with 1 person from my business every other week. It doesn’t sound like much, but it is a SMART goal. Keep in mind that while this seems like a small goal over the course of the year I will have leveraged the experiences and skills of 26 people of varying backgrounds. Keeping this simple will also allow me to manage all the other moving parts without overextending any one activity or another.

Do Not Make Assumptions

Much like in the languages we speak across the globe, a minor difference in pronunciation can make the difference between a bath and a bus. Having regular collaboration time to come up with ways to address the business outcomes is important, but ensures that you leave little room for interpretation. One on one style meetings with the senior leaders may have been the mode before however a fundamental understanding of day to day activities across the broader spectrum may be the route to go. Involving several stakeholders and make them available at these sessions to ask questions should clarify any ambiguities which may exist from both a business and IT perspective

Finish What You Start

Everything starts with the best intentions in mind. Keep connecting with your business to ensure that we are still on target. If you veer off the path, as you inevitably may, make the necessary course corrections. There are no failures with these kinds of deviations as something can always be learned from them. Ensure you share these findings within your community. It can be very easy to fall back into the old routines so keep at it.

As you progress in this new collaborative spirit you still may not intimately know all the business needs but you will be in a better position to ask the right questions to help you both achieve the business outcomes.

Follow me on Twitter @ryanrogilvie