Monday, 29 September 2014

When User Experience and Training Collide

Over the weekend I was in a store looking for an item which was not in stock. I asked one of the staff in the store to look it up and order it so that I could pick it up later. The clerk had a noticeable grimace to which I asked “was there an issue?” they hesitated for a moment and replied “no, but this new system isn’t all that great so it might be faster or easier for you to go on our website and order it that way, if not there is always amazon.”

I was floored, as they basically suggested I go elsewhere rather than them trying to use their system. I asked them if the system wasn’t reliable to which they said “No, the system works, but since we implemented it we have found that we can’t get certain functions to work properly.” The clerk then went on to disclose that they were told that the system is working as designed and that they were not using it right, citing training issues. I now felt a sense of camaraderie with the clerk and asked how well they were trained. He indicated that they were not well trained as he was not the only clerk who was feeling this pain point. When they brought this up with the manager they were told on several occasions that the system was working as it should and that they should read up on the QRC (quick reference card) on the support site to get a better handle on this. The clerk then indicated that there qrc didn’t really speak to this particular issue as it was assumed at some point that this functionality was similar to the previous ordering application.

I thanked the clerk for their transparency, and wished them luck. I could tell that they felt bad that they not only couldn’t help me but were in a position that they had to turn away a customer.

Quite often there is a challenge when a new system is implemented regarding the user experience. Let’s face it some people are not good with change. But should issues like this been ruled out when user acceptance testing was completed?

In some cases, from a change management perspective, we might identify that the new application was signed off by users but we should ask if the users are in any way part of the deployment team or sustainment team. If they are they may have a sense of heightened familiarity with the product where standard questions may not be asked until the application is deployed.

I have found that like reporting, training is quite often low in the importance totem pole. The challenge then becomes how these training gaps will ultimately impact the user experience or even that of the customer as was the case in my experience.

There is a good chance that if the people using the application don’t understand a particular function they will call this a defect. When lists of these are brought to a project team they may review these and determine that some of these were signed off by testers and that that the application just works slightly different than its predecessor. The challenge is to ensure there is a component of training to compensate for these differences. While documentation is good it should complement a well-trained team to achieve excellent service delivery.

In absence of that your teams could simply look for ways to get around this functionality or in my case send the customer to a competitor.

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

Thursday, 25 September 2014

Add a Dash of Marketing for Incident and Problem

At a recent event I was asked about the way the incident and problem management processes were managed. Should they be managed simultaneously with the same people or should they be operated separately. Like a true throwback Thursday, this question still gets asked and likely will for some time.
To get to the root of the question I would ask “What is the real reason that you need to have these processes run in that manner?”

Generally people will say we can’t get addition people or time to do problem management effectively so how can we get around that?

My answer is that it is all about marketing…

You are probably wondering how I got to marketing from incident and problem, but its really something that IT as a whole hasn’t been particularly good with for some time so it’s a skill we need to really work on. Quite often the service management team and some of your operations folks will see the value in having a formalized problem process in an effort to reduce incidents which likely have resources attached. So selling the idea to them is easy, but they may not be the one you need to convince.

The real challenge is that we are always looking at this from the incident perspective, hence the marketing. For example if we were able to apply the same effort to permanently reducing incidents rather than having people fixing them with regularity we may not need additional people at all. To clarify, if we spent 6 hours on a weekly basis to restore functionality to a service, what would happen if we allocated those 6 hours to problem investigation. Doing the math, instead of 468 hours of service impact per year we may be able to spend a fraction of that determining a fix or a workaround or potentially even a way to replace the service to improve perception. This is the way we need to market reactive problem management.
Assuming we can clear that hurdle and allocate resources accordingly, the next challenge is managing the incident and problem activities at the same time. In my opinion these are two different processes which have two different objectives and should be managed as such, and this can get tricky. Without some real focus most often the incident side will bully problem into the shadows and you could be right back where you started without doing any real problem investigation. This slide back into the shadows creates its own negative marketing (there’s that word again) that problem is not as valuable as incident, which is not the case.

Remember that despite keeping the two processes separate by focusing on what they aim to achieve, you still need to connect them together with regularity. This will ensure you are getting a big picture view of where services need improvement and can adjust accordingly.
You might ask me next, “Well that’s great, but what if we don’t have people to do this in the first place?”

Again I come back to marketing and suggest that in the end we are looking to achieve some business outcome. As such we want to ensure that these supporting services enable the business to achieve their goals. If we market the processes based on their merit and what specific value that they add, is it possible that your operations teams could leverage the process to perform incident and problem activities. The touch point may be a regular operations meeting to review the state of services as they relate to incidents and problems.
In summary we need to keep these activities separate, but they cannot exist in isolation. That we market the value of them not only within your service management teams but also to your IT department to ensure that we are all working to the same goal – excellent service delivery

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

Monday, 22 September 2014

How do you relate to your Business?

How do you, whether IT or another department, relate to your business? This is an important question to ask as we strive to achieve business objectives. How do we manage that if we don’t understand how we relate to their needs?

It doesn’t really matter what department you are in whether it is IT or something else, fundamentally you need to ensure your teams goals line up to the bigger picture of the business. What I am interested in knowing is:

·         Do you have a formalized BRM model in place?
·         Do you have something else, some type of ‘go between’ from the business to your department.
·         Perhaps you are relying on leadership to provide you direction.
·         Of course there may be nothing at all that integrates your team’s activities with the business.

In my experience the challenge is that there is always a degree of fog the further up the mountain that you go. Having less people directly involved with the business on their needs presents a risk that we rely on those few to pull us across the goal line. When we have a more communicated and understood view of what the business goals are we are better positioned to discuss regular activities and think in terms of the bug picture with all daily activities. People are able to ask “how will this help the business achieve its goals?”

At the base camp, to use the analogy you are likely to have a collaboration of business relationship managers, service desk analysts, vendor management and support staff in IT just to name a few. At this level of communications and working towards the business goals there are several integrated teams working towards one goal.

As we move towards the summit there may be less of a relationship with the business and the teams which support the business are relying more on fewer people to guide them in a direction which also reaches the same business goals.

Leaving things strictly to leaders presents a challenge of interpretation from one leader to another. As the goals are disseminated to teams there may be small deviations on the initial interpretation which leads to some slight differences to what all teams perceive as the business objectives. I am not saying that this can’t work; the risk is that the devil is in the details and everything rides on the leader’s direction rather than the collective group understanding of direction

So again I pose the question to you. What type of relationship do you have with your business and what success and challenges have you faced as a result?

I look forward to your comments and feedback

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

Monday, 15 September 2014

Customer Experience Team – The Next Transition

We are all looking to improve the level of service we provide no matter what department we work in, whether it is in IT, HR or some other multi-letter acronym. The need to improve is driven by high expectations from your customers, internal or external. From your businesses perspective they are calling into IT support, for example, and have no concern of what the title of the support team is just as long as they can get help as quickly as possible.

Depending on your IT organization the evolution of moving from the term ‘help desk’ to the ‘service desk’ may fundamentally mean nothing at all with the exception of the title. In essence the background to the difference between the two was broken down to what they were meant to accomplish. A help desk, for example is more focused on the person calling into support. They are looking to address fixing issues that are happening right now. For example, I can’t seem to access a particular group folder. The help desk would help this person out by correcting or providing a way to minimize impact through a workaround. The service desk on the other hand takes this to the next level and looks to leveraging other teams to correct this issue for the larger business community which makes it far more strategic.

So, is there a next natural progression from the service desk? Is this where the customer experience specialist or team comes into view? Don’t forget that the customers will still not know the difference on what type of entity they are speaking with. While the intent may be the same, the outcomes are what will be important from a customer’s perspective.

The next question you need to address is at what point does this team then become accountable for all customer experience activity not only with IT issues but HR ones. If this team has the skillset to address customer concerns and is well complimented with support counterparts which have specialties in HR or databases or facilities, how does this impact your organizational dynamics for supporting your shared services within an organization. Your support would then truly become a one stop shop rather than function centric service desks.

Is this even possible?

Getting there is half the fun as the saying goes. You really need to focus on the integration between your customer experience team (CET) and the support teams in the various departments. There needs to be a degree of capability in this group so that all calls which are escalated into the CET can be triaged appropriately.  There needs to be commitment long term to nurture these relationships so that the improvements to this team can be long lived. There also needs to be a level of collaboration between the CET and other business functions such as the PMO, vendor management and business relationship managers – not an easy undertaking

Taking the service desk to another level within your organization is not going to be simple. You will need to continually look at where you are from a service delivery standpoint and determine what level of capability is best for your customers, the help desk, the service desk or something new. As always I welcome your feedback.

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

Thursday, 11 September 2014

Reporting and the 5 Whys

At a recent event I was speaking with someone who said that they were doing all kinds of reporting but it never seemed to make any real difference to their ability to improve the delivery of services.

Reference to the 5 why’s speaks to a style of root cause analysis that asks the question “why” to outline cause and effect.

For Example:
·         The hamburger is cold – why?
·         The order took a long time – why?
·         There was no staff in the restaurant – why?
·         The staffing software did not project the right numbers – why?
·         The system did not receive correct updates – more whys could be asked but you can see where this is going.

While the 5 whys is typically used for root cause, I start to think about how asking why applies to reporting and the gathering of metrics for continual service improvement.

For Example:
·         We had an increase in incidents last month – why?
·         There were more failed changes than normal – why?
·         The lead times for implementations were shorter – why?
·         The business required faster implementations – why?
·         IT needs to be better coordinated with the business to ensure this type of issue doesn’t occur.

More than ever we have the ability to collect all forms of data the question that you have to ask yourselves is what benefit will pulling this information serve. In other words why?

Far too often we extract data in large quantities and are really unable to translate the information in ways in which IT is able to make any type improvement. More is not always better. What we need to ensure is that we align our critical success factors to our businesses goals. From there we can determine what we really need to measure as far as KPI’s in order to make lasting improvements.

So when I asked the person about the data being pulled and said why, there was no real definitive answer to indicate what value the information extracted would provide. It’s not to day that we shouldn’t collect more information than we need, but we need to focus our attention on what outcomes we are trying to achieve with our business partners and then tailor the reporting to line up to those goals. After all, everybody is really busy so spending time focusing on the statistics that matter is time well spent.

Always ask:
·         Why are we reporting on this?
·         What business objectives will this align to?
·         What improvement initiative can we build to achieve the business goals?

Asking questions will allow you to increase your ability to make overall service improvements.

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

Monday, 8 September 2014

Service Management Journey – 100 Posts

I started my blog, The Service Management Journey initially as a way for me to get some ideas written down as well as a way to share some experiences I had within the service management community. Who would have thought I would have written 100 posts so far?

Since many of my posts revolve around reporting on what we have done and what we can do to improve I took a closer look at the high level metrics that I gathered over the course of 100 posts. Interestingly enough when you are in the midst of writing you really don’t think about the breadth of the subject matter so I took some time to break it down a little bit.



The top topics that were read and commented on were what I expected to see. While most of these revolve around larger subject matter these areas always seem to be of particular interest to practitioners in most geographic areas.

As I look back at the percentage of viewers from my analytics it showed that 55% of viewers each week were from the United States while my home country placed a distant third at 7%, while the UK was second at 19%.

As far as the content in the blog I really wasn’t all that surprised to see what the word cloud indicated. It will be interesting to see what differences or similarities show up from this year to next.


What did I learn from this exercise. I think to start with it will help me to not only tailor what content I am writing, but also what audience it reaches. I certainly will be keeping a closer eye on the statistics this year.

I look forward to writing 100 more posts and to connecting with you, the readers. Let me know if there is a particular topic you want to discuss.

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



Thursday, 4 September 2014

The HR Service Center from an IT Perspective – A Trip Back in Time

After last week’s post to the HR community about how the delivery of services to customers from IT and HR in many ways are similar, I was reminded of their similarities directly. In an attempt to file some benefit information I was not able to access a document on the HR system. I called the number for the HR Service Center and after being transferred through a few “technicians” it was determined that this was an IT issue. The HR analyst I was dealing with told me they would transfer me over to the IT support line where I could be helped. While waiting for what seemed to be forever the connection was completed and I spoke to the IT support technician? The unfortunate part was that I had to start all over again since there was no detailed record of the question/answer session that was completed. After I got my issue sorted out I asked the IT support technician why the HR information wasn’t transferred with the call. She proceeded to tell me that it’s not just that they don’t use the same ‘ticketing’ system as IT but it’s that they really don’t track work in that way at all from her understanding. I thanked her for the assistance and hung up the phone.

Interesting, I thought to myself, that this was what the Service Desk may have been like in its infancy. While I felt as though the HR team handled the call, transfer and general information in an adequate way I wondered if there really was no record of this transaction.

The questions then came to me in a flood as I sat there. But the one that held the most weight in my mind was how would are they able to improve on their service delivery if they don’t have some insight into what they are doing or have done currently?

I went up a few floors to see my friend in HR and asked this very question. He mentioned that they have been doing things this way here for a while and it works pretty well.

“How can you know that?” I asked

“Well, no one complains, people seem pretty content with the service” he shrugged

“IT doesn’t get any complaints, but we still look to validate our performance” I added

“That’s because not everyone bothers to tell IT when something sucks after a while” he blurted. It was then that his laughter turned into a realization that he may be talking about HR in the same light.

Seeing that a light bulb had appeared on his face I went on to ask him about how they manage the flow of getting the same calls over and over again. While IT still faces many challenges with this even now, we work hard to reduce those repeat calls to streamline service response. He indicated that they work really hard with the communications group to post reference information and send emails about new benefits or HR functionalities to minimize “question call” as he put it. He even went on to admit that they may almost have too much information for the callers to sift through so they may even end up just calling or emailing the HR service Center rather than looking for it.

I explained that IT certainly doesn’t have all the answers in managing the way the Service Center managed call flows but we have found ways to identify the constraints on the flow in a way which we could quantify a solution and show value on implementing it. We decided to get together and look closer at where we may be able to make things easier for the folks in the HR Service Center.

I love feedback and questions, leverage my service management experiences. Let me know about how your HR Department manages these escalations and what has worked and what has not.

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

Tuesday, 2 September 2014

Back to School Service Management Style – Reporting for the New Term

Where I live, and for many of you, today is the first day of school. What that really means for me is that the summer is over sadly enough, and while kids go back to the books many businesses seem to gear back up and refocus on what needs to be done as well. This is not to say that the summer is a time where this wasn’t getting done but there always appears to be more vigor towards improving after the summer holiday season. It must be the crisp autumn air.

Despite whatever your business challenges are the question from your internal IT leadership will surface, “How well are we doing?”

This is generally asked so that your leaders can get ahead of these same questions being asked of them by business leaders down the line and allow IT to be able to address business executives with an intelligent response. Early in my career I was told that your boss (a term I dislike but use to differentiate from a true leader who operates on a different level) needs to be able to answer the “how are we doing” question in a simple way rather than having a blank stare and an “I don’t know” as a response. The trouble with this mentality is that sometimes we as the operations teams didn’t know either.

This is why in my opinion the right level of reporting needs to be managed and then leveraged to be able to make improvements. The trouble is that we think that the reporting functionality manages itself and it really doesn’t. The business has teams dedicated to analytics after all to allow them to take their business to the next level so why don’t we manage our reporting better. The annual refresher isn’t really the way to go, neither is the ‘we have sunk to new lows and now need to desperately find a way to improve’ method.

We need to start thinking, even in a small sense, of autumn in a quarterly way. If your company is putting out quarterly results and reports we should leverage these to see if there are areas where IT could be helping your business to improve or if there were ways in which IT has hindered the business in some way.

Like an over eager mom in the stationary store we tend to go overboard in these back to school improvements and either gather too much information, or are not in a position to scrutinize the data to validate the accuracy, or both.

Personally I have been in both situations. If you think a boss was angry about saying I don’t know, think how mad they get when the business tells them that their data is wrong or useless.

This is why these quarterly exercises to review the data to make corrections in your operations are necessary. You may not have budget to do a large scale continual service improvement initiative right now but instituting a simple quarterly service management review against metrics will keep your team on point. This will ensure that when your teams  make improvements you will be able to leverage that data for a business case to make getting budget for larger improvement initiatives down the line that much easier.

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