Monday, 30 March 2015

Why is Problem Management Failing You?

I was recently looking in an online service management tool forum site and I saw a post entitled “Problem Management = Fail”. The caption obviously caught my eye and I looked to see the number of responses. There were 48, which isn’t a bad amount of feedback so I decided to see what the topic was about exactly as well as what people were commenting on.

The person who posted this said that while the problem management functionality was easy to implement from the tool perspective that it was not producing the results that their company was looking for. The first response in the timeline of comments asked if they had a process in place or if they were simply looking to have to tool do the work (which is a question I too would ask). The person said “that a process was in place and that they weren’t really getting results before hand and were hoping that their old tool was contributing to the problem.” They went on to elaborate in saying that now they were getting more problems created but not improving the reduction of incidents which they thought might happen.

Looking through the 48 responses I broke categorized the feedback as such:

While this categorization was simple it illustrates that many service management teams may be looking at problem in the wrong way. For me it is all about what your scope of problem management is and what its overall goal is. In short, improve the delivery of service through a reduction of incidents.

Going back to the breakdown of the forum post 23% of the respondents said that they treat problems like incidents. This is a prime example of missing the scope discussion for problem management. If we are spending our problem efforts similar to incidents, we will likely just be following incident management process with the information being filled in a different record type. Keep problem efforts separate.

Problem does not need to be like a unicorn, although two people in that discussion would beg to differ. The reason that Problem sees issues in use or adoption, which encompassed the other concern points, is that we are not looking at the big picture.

Here’s an example, a company has an application which has an issue once a week for several users which has an application hanging for five minutes. After that the application works again. Since no root cause was identified a problem was created and people look at this issue each week. While this might seem like a good candidate for a problem, to some it might not have the value as something else. Your organization might not even be concerned with issues like this and when we report on what we are accomplishing it might look like an anthill despite the impact to some users and incident stats. On the other hand you might have a more visible issue that needs to be addressed and when we review with leadership we can see the value more clearly.

Having a balance to the issues under investigation is important to ensure a great customer experience.

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


Thursday, 26 March 2015

Knowledge Management – Massage Information like Kobe Beef

It is undeniable; the thirst for knowledge must be quenched. Every day people are looking for answers that they need. The question you have to ask yourself as a service provider is “are you in apposition to satisfy their needs?”
One of the fundamental challenges with knowledge management isn’t that we capture the information, it typically stems from the managing of the information itself.
First, why do we need to do this? There are many answers to this question and each organization may have many but fundamentally your community has an expectation that they are able to access data outside the organizational sphere at their convenience so they should be able to do it at work as well.
Secondly we need to know where we should keep this information. In many organizations the data is not located in one place. It is spread across various group shares, wiki’s, SharePoint sites and list goes on. One of the first steps is to decide on a home for that data. This one place will be where the data is stored and accessed. This also allows for us to manage access to the knowledge. After all, some of the information may require certain permissions.
Now that we have decided where, we need to determine what will be in scope for the knowledge repository. Having a scope for the information will allow you to identify the type of knowledge articles which you are going to capture and share with your community. Keep the scope simple to start with. You may decide that self-service “how-to” articles or videos addressing the top 10 calls into the service desk may be the first plan of attack. By doing this you aim to reduce the number of calls into the service desk by allowing people to help themselves out. The time that you save can be applied to curating more knowledge records which could save more time – like a domino effect.
Now we need to identify who. This can apply to a few things:
     1.     Who will be the target audience and who will be able to access the data? Remember that we need to communicate to this community of people that we have this information available as well as some way to “rate” the usefulness so that we can adjust the information accordingly.
     2.     Who will be able to post knowledge records? Will these be the result of incidents, problems and escalations? Or will you be in a position to have a more proactive approach. This control of content needs to be understood and agreed on.
     3.     Who will manage the content? In some cases we may allow multiple parties to upload information but we need to ensure that someone is reviewing prioritizing and in some cases editing the information shared with the community at large.
The trick will be to manage the times that people are able to access the data. As we have information available that the consumer will not need to escalate to the service desk we need a way to track the interaction against the reduction in service desk escalations. The idea is that where there once was a service request there will now be a click on a knowledge portal.
Some might suggest that if the service desk doesn’t need to be engaged will their usefulness disappear? I would suggest that they are content creators. So in essentially they are not dealing with the “small issues” that could be handled by people themselves, they are focusing their energy on assisting with more complex issues and delivering a personalized customer experience where one may be more desired.
Remember that this is not a matter of uploading some documents at regular intervals; this information needs to be nurtured from cradle to grave in its own lifecycle. Continue to communicate the knowledge repository and gather statistical information on its use so that you can build a strategy. Doing this will allow your teams to make lasting improvements which will ultimately improve your overall delivery of services.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn


Monday, 16 March 2015

Incident Escalation – The Devil in the Details

At a recent service management event I was speaking with a manager who was looking to “improve the way that incidents were handled, in both time reductions and amount”. She said that recently they were reviewing the incident records for a self-audit and felt that they didn’t have enough information in them to make lasting improvements.

The tool she is using has a template within it for incidents, which has a standard set of questions. The trouble, as she pointed out, were that many of the questions were going unanswered. A review was conducted of the questions which resulted in the removal of some of them as they appeared to provide little value. Now they only have a few questions which are regularly asked along with additional information which is gathered by the service desk depending on the escalation. To me the questions which are not asked may have more information in them than you might think.

I explained that I have also had a similar experience however I found the questions that were unanswered could provide as much information as the tangible data which was captured.

Here are some practical examples complete with responses and translations:

When did the issue begin?
Response: “I don’t know”
Translation: We may not know when the issue began but we should have an idea when was it working as it was meant to. From here we can fine tune when the issue began even if we are unable to tell exactly when that was by any quantifiable way. For example, this could be the result of a change gone wrong.

How many people are impacted?
Response: “I don’t know, it’s only me, I am the only one on site”
Translation: depending on the business operations you may have very few people on sites where gathering information from a selection of people could be limited. Since this person represents the entire office you may want to investigate what else they are unable to do in an effort to understand any impact beyond what is reported. For example they may not be able to access a particular application but after further questioning you may identify that they can access the network, email, phones. This will help to identify the scope of the issue occurring at their site which might not be immediately clear otherwise.

What steps were taken to reach this error?
Response: “I just can’t perform activity X”
Translation: typically when people escalate some issue they indicate what they are not able to do. In some cases we need to know all the steps leading up to the particular activity which is not working to diagnose what the underlying cause is. You are likely not that familiar with all the workflows of your business. Get the caller to take you through step by step what is working and then what does not. Get a screen capture whenever possible.

In some cases the issue may have nothing to do with infrastructure or applications. It could boil down to communication or training.


We have all heard that a large majority of incidents are generated by changes but what about the escalations that are coming in as a result of a change which is underway. For example someone calls in and they are unable to access application X. in the initial check you identify that they can’t access the application because there is a scheduled outage underway. Be careful how you communicate this to them. We don’t want to belittle them, but we want to understand why they were not aware. It could be that they simply did not see any communication OR that they did not get the communication in the first place. This information should be shared with the manager of the service desk as well as any pertinent service management teams such as change management.


Applications tend to change in both functionality and appearance over time. Because of this there are situations which are escalated that are not actual issues, rather as a result in the person not having the appropriate training for the new functionality. Again we want to capture this information so that we can build a knowledge article in the event that anyone else has a similar challenge. We should also communicate this information back through the team responsible for the update as well as change and release management.

In the end we want to position IT to be able to respond to escalations quickly but to also make lasting improvements through understanding all of the moving parts of the issues which we are working to reduce for our customers.

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

Thursday, 12 March 2015

Building out your Service Management Capability

Call them whatever you like; best practices, guidelines or frameworks, there are a plethora of really good tools which can be used by themselves or in conjunction with one another to enable service delivery in ways which will allow your business to achieve it's goals. 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. The simple answer is that you are already providing some level of service to your business with current processes and activities. The question then becomes what more could you do from a service delivery perspective. Could these missing components take our services to the next level?

Quite often the processes which are not as well managed as the others are limiting the managed activities in ways which may not be clear to you at the moment. Additionally you may not be able to see the missing components since you are "too close" to the work.

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 be limited in the way that you "implement" problem management in the way that you would like to right now, think about what activities will improve your ability to reduce incidents or emergency changes. Start small to achieve the ripple effect that will have lasting effects down the line. This might give you the opportunity in the future where you can re-market it to the right stakeholders when you are able to substantiate your initial improvements with some statistics to back up your claims. 

There is also the voice that says. “We tried putting in asset 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?

To summarize, the key to success overall is to look at what your business needs to achieve. Once you understand what they need you can look at where potential gaps exist in your current method to deliver and support service to understanding what they need will allow you to prioritize what areas you will need to improve.

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

Monday, 9 March 2015

The Dirty Dozen and the 4P’s

Recently I was watching the movie “The Dirty Dozen” on TV. There is a scene where the Major, played by Lee Marvin, reviews the plan of attack with the team as a rhyme to ensure that everyone knows what to do no matter the circumstances. In this particular military exercise precision is priority one to achieve the outcome of survival of the soldiers.

This level of understanding also applies to teams in our organizations with regards to following process. Our goal is to ensure we achieve business outcomes. Far too often we have a belief, whether intentional or otherwise, that all we need to do is implement a new tool to fix all of our issues. That the tool will enable us to achieve our business objectives above all else.

Nothing further from the truth could be true. Many of these “tool” implementation partners will tell you first hand that until you have some documented process they will be unable to have their application work effectively. It really boils it down to process and people.

To give you a real world experience, I went to the doctors for my annual physical. The nurse went through and ran some of the usual metrics such as height, weight, blood pressure and so on. She entered it into the computer, clicked save and then print. She produced a lab requisition form for me to take to a lab for blood work. I was a bit surprised as this is something that the doctor typically did previously. When I asked the nurse about this new system she said that this was a newly automated component to streamline doctor’s visits.  

After she left the room I waited for the doctor to arrive. After a few moments of waiting the doctor came into the office, exchanged the usual pleasantries and then held out his hand and asked if I had a lab sheet for blood work. Surprised, I said that I did and he shook his head, took the sheet and put it in the trash bin.

Seeing the confusion on my face he went on to explain that this new automated lab form was actually the same for all people. That in fact if I was to get these test done it would not only be unnecessary from the diagnostics end but would also require the need to twice the blood extracted at effectively twice the cost to the health care system. He added that if I was interested in giving blood that there would be more value in donating instead.

The report that was generated was not done through a set of doctor requirements; rather it was a “catch all” that would account for any assortment of tests so that less work would need to be done. Basically all people fitting into a set of values would generate the lab request which I got, whether there was value in those test or not. The challenge, as the doctor clearly pointed out, was that without the understanding for the diagnostic process [process] and the interview component between the doctor and patient [people] that the tool generating the lab tests was not doing as effectively as it could be.

The learning point from this is that to get the most out of our tools we need to ensure that all components of process, products, partners and people are taken into account. To do this: Make sure that your processes are documented and regularly reviewed with all partners and stakeholders to ensure that your experience from a tool perspective can be maximized.

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

Thursday, 5 March 2015

Improving Service Delivery from Two Perspectives

I was prompted to think about customer service the other day when I was in line at a bank (yes, an actual queue in a physical bank). The customer ahead of me was speaking with the teller and trying to get a concern across which ultimately required a manager to resolve. Before the person left they said to the manager “it’s about time you got my service right!” I started to think to myself, everyone expects a great customer experience. No one intends on having bad customer service, so why does it seem to be a challenge to deliver one?

The simple answer is that we haven’t enabled our service providers in a way which promotes delivering exceptional service. To put another way just about everyone can make a sandwich, however a chef is more likely to deliver an exception one as they have fined tuned their skills and have tools to assist in making the better product.

So what is the element that differentiates from an average customer experience to an exceptional one? In my experience on of the first items to address is the assumption that we, as a service provider, knows what the customer wants.
We need to understand the customer.

From the service provider angle

There are a couple of ways to attack this one. First look at it from the perspective of what you already know by leveraging your own metrics. Get an understanding of what services your customer consumes, what issues they are facing with the services, how quickly (or not) services are provisioned or restored in the case of issues.
Caution: your metrics are likely to have some flaws so this is why using your own data can lead you to assume you know what the customer wants. This is probably how you have assessed your ability to provide service in the past and it is only half the equation.

From the customer angle

You really need to speak with your customers regularly (not once a year) to see what is working well and what areas can use some improvements. Have some strategy on how you want to solicit information from your customer base. You might decide that reducing time to completion for requests is the top priority. So when you ask your customers about it don’t have vague questions which will have answers that will provide little value for your improvement strategy. For example “how would you rate the speed of service – Great, Average, or Bad” The answer to these may not help you to improve anything as they do not necessarily tell the whole story.

Put the two pieces together

My suggestion is to do your homework first. Find out what the services look like who is doing what and when to target who you will want to speak with. Next look to see from your end what may be working well or not. Then go to your customer armed with some data to discuss these details. It might sound something like this.

Service Provider: “It looked like in the past 3 months we have seen an increase in the amount of requests as well as the duration of those requests for application x”

Customer: “Yes we have started a new marketing blast for our customers that has increased the need for not only new associates but the roles that they need to get their work completed:

Service Provider: “I see, is this a seasonal promotion or something that is long lasting?

Customer: “actually in the coming months we are looking to expand our sales globally”

In this example you can see that the dialog has indicated that there was an increase of use as a business requirement and that this is not expected to drop off, it is likely that this use may even increase. This knowledge should allow you to address the fact that from a customer delivery perspective we need to make some adjustments but passing this information along to internal support teams may help to ensure that the application in question is robust enough to handle further use, which would also in the long run help service availability and promote an excellent customer experience.

In short, understand what your customer needs as well as what you are currently providing and this will allow you to have better discussions with them around improving service delivery.

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

Monday, 2 March 2015

Build a Service Management All-Star Team

I was recently speaking with a service management practitioner who was looking to revisit a service management improvement strategy. When I asked her what she was working with she indicated that her organization was looking to build out its service management capability regarding the following processes: Change, Incident and Request to start with.

The initial component of the project, which was completed was performing the gap analysis from where they are today and where they need to be. The company had outlined several roles which needed to be filled but like any company these days identified that money is an object and that they need to be selective with the overall operational cost of the newly rebuilt service management team.

My advice to her was simple. Quality vs Quantity.

You want to position yourself to have the people filling these roles as agents for change for the ITSM project. The reason is simple, you need to have people who can not only manage the work but be advocates for the work being completed. In many cases their skills will need to allow them to train material, be able to market the processes to those who do not understand them as well taking metrics and translating them into something tangible for lasting improvements.

I suggested that her efforts in the initial component of the improvement phase would be best served having these types of people compared with more warm bodies occupying seats. I went on to state that rather than hiring 5 people of average skill if they were to have one all-star in each of the three roles you would have a better shot at not only delivering value but sharing the success that goes along with it.

After all, when it comes right down to it being able to show tangible results will allow to further grow this improvement initiative in future phases over the long run. In cases where you do not have these advocates you may run the risk of implementing processes with process managers which will keep the business operating but not enable them to take service to the next level.

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