Tuesday, 28 April 2015

Sharing Ain't Easy - But it Could Be

After recently sharing a post which was entitled The Value in Sharing in ITSM, I started gathering feedback on the subject which, in keeping with the theme, I will share. The post was part of a larger sharing exercise for me where I was also presenting on the subject at a local itSMF breakfast event.

Much like in the post, my presentation took the audience through my beginnings as well as what I learned along the way. I also shared with them some links to great content to check out on their own (which I have added to the bottom) I did point out that these are some of the places I started out with and by no means are a summation of all the places I go to for that collaborative spirit.

The feedback I received basically fit into a few categories:
  • Why do you do it?
  • How do you do it?
  • I am glad you are doing it….

In the “why” category people were most often interested in why I would do this at all. In some cases a few people commented that there is loads of information out there so why do I feel the need to add to content that is already there? I have always maintained that I enjoy the other content I consume, however for me, I find that I simply learn better when I start to take pen to paper as it were. In some cases this is a selfish activity of self-discovery for me. the other reason I like to share my thoughts is so that they can be challenged and I am able to learn from others as I gain insight into other viewpoints from other lines of business and cultural backgrounds where i might not otherwise have the opportunity.

There were also quite a few people who ask “how”. Who has the time to do this in the first place? Don’t you have a job and family commitments ect? The answer is yes, of course, although anything worth doing isn’t always easy, just ask Big Daddy Kane. My ability to "do" this is an exercise in time management. I set out with a realistic goal to post regularly and use time which I was normally spending on going back and forth to work on the public transit staring out the window to capture some thoughts.

There were also some people that appreciated that I was sharing information with them. Not just my content but the content of others. For me this is the most important part. There are so many great places for information and there are more every day.

I appreciate your feedback

Here are some places to check out, certainly a start and not a complete list. Feel free to share a list with me as well.

James Finister
Rob England
Barclay Rae
Greg Sanker
Ken Gonzalez
Mika Salo
Stuart Rance
Vaughan Merlyn
Daniel Breston
Mark Thomas
Various writers
Various writers
Matt Hooper
Various Writers
Joe the IT Guy
Charles Araujo

Twitter Accounts

Monday, 20 April 2015

ITSM Conferences - Eeny, Meeny, Miny, Moe

Eeny, Meeny, Miny, Moe, To what ITSM Conference should I go?

Do you find yourself asking the question, “What Service Management conference should I attend at this year?”

This will likely depend on budget and ensuring that the conference you attend has value add to account for budget as well as the time you are away

For me the challenge has been in the grand scope what events are available for me to attend that I may not even realize existed in addition to the ones I know. There are a few highly marketed conferences that we have come to know and love from the ITSM space such as those from HDI, Pink, ITSMF, and of course the ITSM tool vendors just to touch the tip of the iceberg. But unless you are a constant on the conference circuit and know what each of the events offer and when they are scheduled it may be a little more difficult to navigate the sea of choices. Is there a place to see all that there is to choose from with regards to the service management space so that you can make an informed choice on what conference(s) you can attend in the upcoming calendar year. Surely everyone would love to go to Vegas but are there more regional events that we are not aware of? Whether they are physical or virtual online events.

Are these lesser known events looking for volunteers or attendees and are not hitting the target audiences? Would a conference repository help them to promote to those that might not attend otherwise. Remember it’s not always about ITSM specifically. It could apply to Governance, Risk, BRM, Cyber Resilience, Training or even other activities which are driven by IT which impact your business goals.

If you are aware of any of these repositories in part or in whole please feel free to send me a link at +RyanOgilvie on twitter at @ryanrogilvie or on Linkedin

Wednesday, 15 April 2015

The Incident Management Paradox

A connection of mine on Twitter was looking to hire an incident manager within their organization and was wanted to bounce the job posting off me to see if there was anything that could be added or removed in the post. Since many organizations are looking to cut costs wherever they can I asked if this was a replacement person. They said that they were looking to hire an additional person since their incident rates had been going up.

As I read this I had two thoughts. On the one side, this organization was looking to ensure that they were able to manage the issues that they were seeing as effectively as they could. On the other hand that same organization is enabling the mismanagement of issues by not understanding what drives them in the first place.

Here is an example. If we had a performance issue with an application and the suggestion was to bolster the clustered environment buy throwing more servers at it we could fix the issue. That would work but what is the value proposition of doing that? Not particularly good I would say.

Eventually when we are looking at a value of the service we are providing this just does not make sense.

The addition of the incident manager is a similar situation. We should have a fundamental understanding of what is driving these issues in the first place. While initially we may need this person to handle the flood of work that is coming in I instructed my friend to think of a long term strategy to reduce incidents in the first place.

To start, take a look at the top 10 issues which you seem to be facing and determine their source. By source I am talking about breaking it down into chunks like this:
  • Application issues – IT
  • Infrastructure issues – IT
  • Training Issues
  • User Perception
  • Project Related

There are a few others you could use but this will at least target areas where we as an IT capability can look at some issues and where we may need to look at other teams to help facilitate the issues which are being experienced.

While the application and infrastructure issues are fairly straight forward, training issues may apply to the way that training was handled after a new tool was implemented or updated and as a result we may need to vet similar rollout or updates in a more managed and consistent way to reduce these escalations.

User perception issues are similar in that they may have expected something as a result of a deployment and are not seeing what was expected, this could be a result of communication breakdowns or user acceptance to name a few challenges but we need to know what they are if we are going to build a strategy to reduce these.

Depending on how projects are transitioned into operations we may see a combination of the two previous examples or in some cases if IT was not looped in throughout the project until just before ‘go live’ we may have other issues which are being escalated which could have been prevented.

In the end IT needs to broaden its understanding of the services which it provides so that it can take a list of issues and plan a strategy to reduce them one at a time and improve the customer experience overall.

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



Monday, 13 April 2015

Mixing up Great Service Delivery through Problem Management

After listening to the Hacking Business Technology podcast I was thinking a bit more about Problem Management.
Typically the discussion sounds like this:
IT Leaders: “We want to reduce incidents and improve service”
IT Support: “OK, we will look into that”
IT Leaders: “Great!”
Wait for the deafening silence.

While all people in IT are looking at each other and shrugging shoulders they are already working towards this goal. The trick is that we may not have enabled them with the capability to actually achieve this goal.
Regardless if you have a formalized way at looking at problems or not you need to have the right components playing into problem analysis to actually be able to make the service improvements you are looking for. It’s like having a two or three legged table. It might balance for a while but overall it is not going to work as well as it could.

I like to look at problem management like a cocktail. For it to taste just right you need a myriad of ingredients. Here are a few of my favorite inputs and why.

Post Implementation Reviews
There are two components where these can help you identify areas where issues arise. The first as it pertains to failed changes which cause incidents. I have said it before, sometimes the incident records and changes are not linked in a way that will clearly show continuity. So this documentation will connect some of those dots. Look at the ones you have from last week, or last month. What services are they impacting, what went wrong with these changes? The other post implementation review that should be looked at is as a result of emergency changes. If we need an emergency fix this also should also point us in a direction that shows where some issues lie. Particularly if we are doing “routine” emergency fixes

Critical Incident Post Mortems.
Critical incidents will happen from time to time, this is a reality. However making sure that we learn something from all of these issues is important. We should be asking the people who are in these reviews if we identified what caused the issue and what we are doing to ensure it doesn’t happen again. If we don’t know, or worse yet the issue was fixed by magic, we might want to see if this is something that we can dig into further.

Weekly Stats
Looking at “the numbers” we should be able to ascertain some basic form of trend analysis. Are we seeing an increase in the number of incidents, requests or changes? If so why is that the case? If we are seeing an increase in one of these there is a possibility that the others will see an increase as well as I pointed out in a previous blog post “The Yin and Yang of Incident and Change…”

Team Touch Points
Having a discussion on the flow of work within the IT organization will also allow you to see what challenges each other are facing. In some cases there are silos with the IT team which are preventing the whole to understand the challenges the parts are facing. It is possible that an infrastructure team is seeing an issue that could be addressed by someone’s expertise or experience in the application support team or vice versa. Utilizing the larger knowledge base will allow you to see things in a broader way.

Business Touch Points
Having similar discussions with your business will also allow you to see what you in IT may not see through your current reporting capability. There may be cases where apathy has prevented the business in escalating an issue. Another example is that we may not truly understand a particular business service we are providing and may be underplaying its importance from a priority perspective. All these discussions are important and should be had regularly. Whether you have a formalized role such as a business relationship manager or not you need to understand the services which you supply.

Having these tools in place will allow you as an IT organization to build out your capability to make improvements on issues your business is facing. Your business needs to have a strategic ally to allow them to achieve their business objectives. Whether you call a process problem management or not matter as much as the actions which are helping facilitate that success.

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

Monday, 6 April 2015

The Yin and Yang of Incident and Change and its Impact on Service

In an attempt to schedule an afternoon social I ran across the quandary of finding a time that was suitable for all my colleagues. One such person, who shall remain nameless, had said that the service desk that they work on is overloaded with incidents on Wednesday so that wouldn’t be a good day. They said it had to do with the way that they changed the date that the CAB convened on a few months back, and this was the cause so for as they could tell.

It turned out that CAB had a better attendance, due to availability, on Monday vs Wednesday which was when they used to have the CAB in the past. This got me thinking. What does the cycle look like from the implementation of a change, into an incident in some unfortunate situations, and into a resolution of those incidents through another change (or roll back).

Looking at this example closer we have a CAB on Mondays which allows changes to be implemented (for good or bad) as early as 24 hours later, in this case Tuesday. When issues arise from these changes we are starting to see them on Wednesday which correlates to the influx of incidents. As a result, depending on the circumstances, some changes are reverted to a pre-change state while others require an emergency change to be implemented to correct these issues.

To me the issue seems obvious. However I often find that the obvious is only seen by those who are looking at it with fresh eyes. Those who are waist deep in the situation may not see it as clearly as someone external or if they can see the issue cannot visualize the solution as clearly. When I asked my friend about it they said, “I think we have always had incidents as a result of change but since the CAB date change we don’t get as many of them on Mondays like we used to, so it seems as though it has improved.” They continued to say that in actuality the number of incidents now is just more balanced and this is why the issue isn’t pressed as hard from an IT perspective.

Wait a second… I thought that they were putting me on for a second but they weren’t. I had to ask about the fact that they were simply moving the issues from one day to another without addressing the main issue – the fact that changes were failing. Despite the fact that the issue isn’t that “pressing” the end result is the delivery of services. Iuf you were to ask them about the issues the customer might suggest that the service has not improved one bit over the course of time, and they would be correct.

As you can see in the picture below, from a customer experience perspective the issues are still present despite what day the changes are implemented. If you were only to shuffle the days at the bottom axis around the humps which represent changes and incidents remain.

“Why does no one see that this is an issue?” I asked.

The response was that they report on service management metrics (incident and change) separately and do not connect the dots between the two.

That has to change, I insisted. As a start I would look at the following:

1.     The number of changes which cause incidents and/or are rolled back. In the case where changes are not updated to reflect any issues and we see a high rate of implementation success (and if the two teams are not working collaboratively this will be likely) we need to see how many emergency changes we are creating and why. Even in a state where change is measured in a silo we should see that a change caused an emergency change.

2.     We may need to take a look at the timeframe where something is reviewed in CAB and then implemented in production. It might be possible that the changes which are not successful are also the ones which are being implemented 24 hours after CAB. Knowing which changes are impacting the business in a negative way will allow us as an IT organization to better assess what is not working as well as it could be an build a strategy to improve it.

Whatever it might be we want to ensure that the customer is getting a good experience and that we are not reviewing the provision of that service as a unit through our metrics by challenging the inputs and outputs for each process as it pertains to delivering service. Getting these teams together regularly with key stakeholders will allow some visibility on the areas which need improvement to better provide a solid customer experience.

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