Monday, 22 February 2016

Do you work with an Incident Barometer?

At a recent service management event I was sat at a large table with various service desk managers who were reminiscing about incidents similar to someone reliving old athletics stories from when they attended school. While all the stories were different and amusing in their own ways, there was one common thread to them all. Each company seemed to have a person who always escalated the issues with regularity. They were THAT person.

No matter if the issue is noticed first thing on a Monday morning or on a seemingly slow Friday afternoon, when you see their name on the call display you know that potentially nothing good is happening. It is almost as if these people unknowingly have an ability to find errors and issues that some other may not see or overlook. They can almost sense an incident.

When I suggested that they were an Incident Barometer most of the people laughed, but despite it being comical in nature I thought how we need to harness this power for the forces of good.

Anyone who has dealt with people escalating issues knows at least this one fact. People will only escalate as long as they feel it is getting them some value. If they escalate an issue and don’t see results they will stop escalating. Some people might call this the WIIFM factor. Call it whatever you want, if you have someone escalating with regularity we want to find ways to not only ensure that they continue to do so but also channel this energy into other activities.

For example, one such activity might be to have them performing additional user acceptance tests for changes which are being implemented. While we want to admit it or not we know that changes can cause incidents. We might be able to improve upon this if we insert a person who uses the tool regularly and often is looking for and identifies issues post implementation.

Another example would be to get their input regarding training programs which could encompass new functionality releases all the way up to go-live events for new tools in general. Leveraging their experience may generate many questions that can be reviewed by a project team early on to allow them to get in front of this before they get to the actual training where these questions may be raised. Addressing these questions or concerns as a requirement rather than a function of training or deployment will minimize business impact down the line.

Whether they are escalating because they are in early, because they are a manager or some other reason, the fact remains that they are communicating with you. It is your job to continue the dialog. Doing this will allow you to continue to improve your relationships with the business and enable the improvement of service delivery.

Now it’s your turn, do you work with an incident barometer?

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

Wednesday, 17 February 2016

Well Rounded ITSM

The other day I had a chance to catch up with a colleague who was eagerly anticipating the start of a new incident manager in his group. He explained that they had quite a few really good candidates, but the role was a large one and right now they were feeling the crunch being short a person.

Initially I thought that they might have been looking for someone to oversee the process but it turned out that they really needed someone with experience at the role of managing the incidents and to be able to hit the ground running since there were quite a few issues each day that needed to be managed to resolution by a seasoned pro.

Because I am curious, and this discussion was already starting to prompt me for a blog post, I wondered what he meant by dealing with loads of issues each day. We explained that it wasn’t one thing that always was an issue it was that within the sea of applications and infrastructure they supported there always seemed to be an issue with something.

“Bottom line, it’s because our change management process isn’t very mature, we still have loads of issues as the result of a change going bad.”

He also outlined that many mornings seemed to be a panic state, people were correcting small issues from a change gone sideways or that a change had not completed on time. The perspective from the business was that there were regular issues. The reality in these types of situations is that suppport teams tend to go into firefighting mode, and as we all know once you are in that state it can be hard to get out. we can hear our business say "Get it fixed as fast as possible"

They did this so well that the incident team was required to have a mastery of resolving issues, so much so it was an expectation. The trouble here is that because this process was not really working in a well-rounded way with other inputs and outputs there was no real way to make overall lasting improvements.

This is likely a loop that will continue until they stop and take a closer look at the big picture.

Let’s expand this one level
Why are we seeing issues in the first place? This isn’t to say that we are looking for what caused the issues. This is typically how this incident centric organization ended up in this rut. They are consistently looking at the technical reason that these failures occur but are not applying what they find to the area that will improve this situation. In reality when we start looking at a larger, more process centric view, we can see that the change management process clearly has some areas for improvement since we have several failed changes or changes which exceed their windows.

Expand one more layer
The magnification for the issue shouldn’t stop there. Once we make an improvement in the initial process we can look for what inputs and outputs are still gaps and make some enhancements in those areas. It’s almost like a domino effect. To continue with this example this organization might focus on processes within Service Operation or Service Transition, but we should also start to think about what this looks like from Service Design and Strategy. For example as we look to make improvements within change management we might find that this is the result of how we manage demand from the business.

Expand one more time
If we were to magnify this again we might identify that all causes for our challenges are the result of poorly managed communication. Do we know and understand what the business outcomes are? Are we in a position to know or understand what they are? When we ask these questions we need to really be sure that we can get the answer without any level of assumption. Are the business goals clear and do they drive the overall decisions that we make every day within the organization.

While our ability to restore service as the result of an incident is important, having a well-rounded approach to service delivery is far more sustainable in the long run. Continuing to pile on resources for break-fix work has no real value. It is also detrimental to improving and fostering a partnership with the business that you support.

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

Tuesday, 2 February 2016

Make Improvements and Avoid Groundhog Day

If you were to look back at how your organization has handled certain initiatives over the years it might look like they are in a repeating cycle of trial and error.

For those who may not have seen the movie “Groundhog Day” it is a story about a weatherman (played by Bill Murray) who wakes up every morning and it is February 2nd. No matter what he does throughout the day he will wake up the next morning on February 2nd - Groundhog Day.

Does this sound familiar?

There are times where we might find ourselves in this same type of endless loop where no matter what we do, we end up at the start with no measurable improvement.
So, what do you do?

The trick here is to start to think why it hasn’t worked in the past. It is likely that we already know, and understand why we are in this seemingly endless loop. In fact we are probably complaining about it in repeat mode to just about anybody who will listen.

The first step is to stop and really think about what is the roadblock for getting your goals accomplished. When we run through this exercise, don't focus on only immediate constraints, think bigger scale. For example if it is related to someone in leadership who is challenging this activity. Understand what is preventing them for seeing things in a way which moves us forward. Avoid the blame game as this is never going to help produce results.

As an example let’s suppose that we are having difficulty getting problem management off the ground. We all know that there are many positive benefits of this activity so why are we not performing it. We know that to improve service we want to reduce the number of business impacting incidents. Sounds simple enough, so let’s break down the reasons that our example organization is not able to jump this hurdle.

Out team doesn’t have the people to do this work
Instead of using this as a crutch, let's focus on how we can get around this. Many organizations will say that they don’t have the bandwidth for other activities. Perhaps we need to find a way to ensure that the teams that are impacted by the incidents have the tools to investigate and manage the issues in a proactive way. We may not have a ‘problem manager’ but by managing the work load we can reduce the waste work generated by incidents. People might just see this as ‘more work to do’ but if this added effort is marketed in a way which shows long term work reductions than we can move the needle on this.

We don’t get traction with the problems that we work
Firstly. Make sure you are working on the right things. Working on an issue which might be the result of a memory leak might be a suitable problem by the books, but we need to start thinking outside of that thought pattern if we are going to gain some momentum on how problem is perceived. Is the work and results of resolving this issue going to do that? Instead we might want to take on a problem that impacts tasks which would be better if they were automated (password resets) or even training issues that could be managed by a knowledge article.

No one understands what problem management is
I have news for you, they don’t actually care. However they do care about what a solid problem resolution can produce - results. Learn to celebrate your successes. Communicate when you are able to achieve wins by making progress. Even if they are small to you they can build up to something substantial.

In the movie Groundhog Day the main character, Phil Connors, is finally able to escape this loop by connecting with the people in the town of Punxsutawney where he is trapped as well as sharing his experiences with them to improve their lives.

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