Monday, 27 May 2013

The Forecast Calls for Clouds – Talk to the Business


We have reached a point in time where your business is expecting to be more empowered at work, much like they are at home, some of whom have been there longer than others. They have high expectations with regards to tools and their availability. They want them to be collaborative and easy to access. It is in these where your business may find challenges with enterprise applications and see IT as the “bottleneck to their financial progress”. There will be a point (if it hasn’t happened already) where your business might say “that’s ok; I will just expense this new application and not have to wait for IT to drag its feet!” In other cases where the customer base may not have that financial freedom and they may search out free software. It is even possible that since the dialog between IT and your business has been lacking that they are already using these services (SaaS, PaaS, or IaaS) in some capacity without you even knowing it.

How we got to this point, you may ask yourself. To start with IT as a unit hasn’t been particularly good at marketing itself. While our cloud competitors have marketing teams that help them , they are likely telling your customers that they “feel their pain” when it comes to the slow processes that “hang them up” even though they are probably following the same best practices.

The way that you need to start having conversations with your business is about their service. They will be more inclined to discuss their goals and challenges that face them rather than the processes you employ, so start the discussion on that level. If your customers are shopping for another service provider, find out why? What is it about their current service that is the issue? You may be surprised to find the results. While you may even think to yourself that the cloud is the best option given the business needs you are in a position to stay ahead of the curve. Where before you may have been the last to know? It is even possible where your service desk had an escalation for a service that was being used by your customers that you had no idea was even in use. How does that impact the image of IT when you seem completely unaware of an entire application?

Granted, if you have some maturity in whichever processes you are currently using, even an IT organization in a silo should be aware of what is happening within the customers environments. The communication with the business is the great equalizer for this. It may even help you to determine where immediate improvements within the way you deliver services may be possible. Regularly scheduled discussion points with the business stakeholders would probably produce some a-ha moments that previously were unavailable.

Remember, the cloud also has outages, despite what degree of 9’s your competitor is talking about, things can still go wrong. The less we know about our business , the more likely that they have some service(s) we do not know about. Our cloud competitors also have sales staff whose sole function is to sell their product. They will tell customers that application “A” has a plug in for application “B”. While this may be true if IT is not available to review this there may be some issues with application B down the line. And it is possible that without any knowledge our service management processes will not be able to perform the activities that the business needs.

Overall the theme here is to stay engaged with the business on all aspects of their service needs. It may not always be easy, but the returns on this is invaluable.

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


 

Tuesday, 21 May 2013

Dad, what do you do? – The Service Management Café


When I was a kid I was easily able to articulate what my father did for a living. He drove the bus, this meant he picked up passengers, dropped them off and drove in a route to repeat this activity. If you were to ask my wife what I do she might have some idea but may not be able to explain it in terms other people may understand. Her common response is “he is an IT geek”. This may offer its own stereotypes but most people have a notion of what that equates to.
There becomes a time where when the business units you deal with may not “get” what you do but they may have a preconceived notion of what IT represents. It is time to change that mentality by becoming partners with the business.

I am pretty sure that most people have eaten in a restaurant at one time or another and in some cases even worked I one (I can fondly remember working at the Edinburgh Rock Café many years ago ). This is why I tend to use this as the example in my explanation

Here are the roles as they pertain to this particular example:

Restaurant
Information Technology
Customer
Customer
Expediter
Incident Management
Sous Chef
Application Support and Delivery
Head Chef
Change, Release and SACM
Cleaners
Operations Team
Line Cooks
Operations Team
KP
Operations Team
Bar Staff
Operations Team
Manager
IT Operations Manager
Doorman / Bouncer
IT Security
Servers
Service Desk
Owner
CIO
Note depending on geographical location terms for these positions may vary

Breaking this down into a scenario would sound a little like this.
The customer heads to the ITSM restaurant at lunchtime for soup, sandwich and a pint. When they arrive they give a nod to the doorman, (IT Security) who ensures they have reservations and that they are not part of a large tour group. The customers are seated next to the window and given a menu (service catalog). The customer is impressed with the cleanliness of the restaurant and frankly the cutlery, since some experiences recently have not been as positive. “They must have a good staff (Operations Team) to keep things this clean”, they mention among each other. After a moment to review the menu and decide the customers tells the servers (Service Desk) that they want the soup and sandwich lunch special. The server places the order and the customer eagerly waits for their beer. While nothing has been formally discussed there is an unsaid agreement that since this is lunch hour that the service will be quick (Service Level Objective)

As a function of the order (Service Request) the pint of Guinness has been pulled, allowed to settle, and delivered to the customer. (This is my scenario and in it a pint of black is the way to go)
In the Kitchen the expediter (Incident Manager) sees the order come up and calls it out (escalates) to the kitchen staff (our operations team) to assemble. During preparation process it is determined that the soup de jour has run out. Because the Chef did not have the correct ingredients in the kitchen (Configuration Management) they were unable to make the chicken noodle soup as requested by the customer.

It is at this point that the Sous Chef discuses with the Head Chef the alternative solutions (problem management workarounds). Making a garden salad as a substitute is the plan. This information is relayed through the wait staff to the customer. While the customer had their heart set on the broth, they agree to the salad option. As the order is assembled it is checked for quality before it is… deployed.
The customer receives the salad and sandwich combo and enjoys it thoroughly. This may not always be the case. In other examples this same customer may bring up a complaint with the manager (IT Operations Manager) or the owner (CIO) if they are aware of whom they are.

This example is simple, and while it is subject to interpretations and variations the point is this. When discussing how service management helps the business, no matter how apparent it is to you speaking of it in terms that the business understands (not processes) s paramount to helping to become partners with them.

Follow us on Twitter @ryanrogilvie

Monday, 13 May 2013

The Rate of Return on a Sandwich


I was recently reading an article that was talking about ways to cut costs that were so incremental that no one really had noticed but had a large effect on the bottom line. The article in particular said that in 1987 an airline removed 1 out of 4 olives from the salad which its first class passengers frequently enjoyed. This cost savings amounted to around $100,000 per year. This got me to think about how you could leverage business engagement activities in small ways to over a coffee or lunch to mirror this type of success.

Let’s assume for a minute that we want to improve our business relationships. One of the key things we first want to look at is how we are aligned internally as an IT unit. Are we cohesive enough to understand what activities we are performing to provide the business outcomes that our customers require. Before we get ahead of ourselves we should ensure that our own IT activities are aligned to achieve what the business outcomes are. Sometimes, but not always, IT tends to focus on the work at hand and complete tasks in their own silos which may not quite get us the entire distance.
Once we have alignment (and it’s an ongoing activity in its own right) we can really focus on how we can help the business achieve their goals. In some organizations they may have the “Top 5” goals for the year posted on a wall or a intranet site, but what we need to better understand is from the customers perspective how are we going to be able to help them do that. The answer is we ask them.
Spending time with the customers to see what is working well and what is not is key to achieving this goal. We may have made several assumptions on what we think the customer wants without even spending the time to find out from them. This activity may be as simple as quick coffee, elevator chat, visit of a team meeting, etc.
I can already hear some of the “yeah buts” so to dispel with a few I will run through the list of what typically pops up as an excuse:

1.     I am too busy

2.     Where do I start

3.     Isn’t this something senior leaders are already doing

4.     Maybe the customers are too busy

Here are some answers to the above
1.     I am too busy
Everyone is busy, but let’s suppose that without soliciting information or having customer insight you find out down the road that the requirements that you had put together or were delivering / supporting were incorrect and had to be reworked. Would that few moments in time have saved you all the rework?
2.     Where do I start?
This can be daunting, but everyone in a support role has some sort of key into the customer base. Leverage those connections to make others. Relationship building isn’t a one person activity, if your entire department takes it upon themselves to reach out to you will be able to cover off more ground than you can imagine. Document any important information about the business workings you discover and share them with your team as well. Knowledge is power they say.
3.     Isn’t this something senior leaders are already doing
They might be, but you then have to wonder if there a disconnect between IT and leadership similar to you and your customer, after all they are customer too. Talk with your IT leader to see what connections are happening and then challenge your leader to keep you as informed as you can be.
4.     Maybe the customers are too busy
Again, everyone is busy but if you engage with the business in terms of helping them to make their customer experience as positive as possible they won’t mind spending a few minutes to help you help them. Even if they are satisfied with the service, providing what is working back to your IT support team is a step in the right direction.
It would be interesting to see what initiatives are started over something as simple as a coffee or sandwich and what returns can be made on the simplest investment of time on your customer experience and bottom line.

Let me know what experiences you have had, what has worked or not so much


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


Thursday, 9 May 2013

Service Management metrics too good to be true


As a bit of a numbers junkie I like to look at the stats and see what they tell me. As the old saying goes if it is too good to be true than it probably is. So with that in mind, when we have measurements which are accurate with regularity and we see something that can’t possibly be so, what do we do? The answer is that we may need a way to verify against another set of information.
Here is an example:
We have received our monthly Change Management stats for the previous month and it indicates that of the 250 changes we made we attained a 100% success rate – fantastic right? Immediately the skeptic in me wants to ask questions. Let’s assume for this examples sake that on average we have 2 or 3 failed changes which result in a total of 10 reported incidents each month normally. This is where we tie in the other service management processes. From an Incident Management standpoint are we relating all the potential reasons to the correct source? This is not the only challenge, another might be that the impact from the change may not directly impact customers until well after the implementation has been completed and when incident staff attempt to tie it back the description of the change is not obvious enough to make an accurate correlation. These incidents which have no “apparent “ root cause should at the very least end up in the lap of someone who is working your Problem Management angle. Since the implementer has completed the work and testing they have determined that this implementation was a success. They have likely closed off the change as successful as nothing has been shown otherwise. Nothing wrong with that, but once this new information surfaces the closure code should be updated to reflect the change in status.
That was when the numbers look too good to be true, however in reality we should have a check point to ensure that this doesn’t happen in the first place. The first time that it does your stakeholders, whether they are customers or IT, will start to question all statistics and their validity from that point forward. A major benchmark of this is with uptime. Much like in the example above if we hit an astronomical number; our business may call us out and say there were several outages that may have not been tracked appropriately.
To remedy this, a regular (weekly) meeting with your Service Management functionality and IT stakeholders should take place to get alignment on the activities that are happening in your environments for a particular time frame
This activity will allow your Incident team to see what changes are scheduled in the next week and ask appropriate questions on what may cause customers to call in with any potential issues. It will also allow your Problem manager to determine if there are any new problems they should be focusing on or reprioritizing the ones they are currently investigating. As in this example your Change manager will be able to identify if any changes which happened in the previous week had inadvertently caused issues which could be avoided next time.

Performing these checkpoints will allow your teams to be more confident that when the numbers are this good that they actually are.

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


 

Wednesday, 1 May 2013

Service Management Frameworks - We do this process on Tuesdays and Thursdays

There are a plethora of really good frameworks or best practices which can be leveraged for service management and you may already be employing one or more of these to accomplish what your specific business needs are. In the background, however, there is still a discussion that is going on that sounds like this:
        ·         “We do this process really well, while this other one, not so much.”
        ·         “We have to do Change and Incident but not Problem.”
        ·         “Release and Configuration management are kinda part of Change, but not always”

How is this in fact impacting the way you are able to deliver service through the processes which you are doing really well. Could these missing components take our services to the next level?
Quite often these adhoc processes are not after thoughts, which are how it may look from the outside in, in some cases there are formalized process that are documented but not managed effectively.
It’s time to take a closer look at these and determine whether the inputs and outputs are impacting your currently managed processes. While yes, it is possible that you may not have a way to institute problem management in the way that you would like right now but leveraging it in a way that currently makes sense to your business today may help to reduce incidents. This might give you the opportunity in the future where you can re-market it to the right stakeholders proving out an ROI analysis that may enable you to formalize the process further.
There is also the voice that says. “We tried putting in configuration management in a few years back and it was an epic failure. I don’t want to bring it up again.”
Just because something didn’t work then does not mean we can’t try it now. First we should look at what went wrong when we attempted it last time. Learn from your (or others) mistakes. It is possible that our current process has had time to mature since then. It is also possible that we approached this process the wrong way or the timing for our organization wasn’t appropriate, do we have any take-away items from then we can action?
Having inconsistent approaches to these less than formalized processes can also cause confusion for those who may be inadvertently associated with them. These need to be dealt with either by formalizing some piece or deciding to shelf it until a time when it can be re-visited later. There should be someone who owns them even if they are less mature.


Follow us on Twitter @ryanrogilvie