Wednesday, 28 January 2015

Showing Service Management Value: Change Management

So far in this series we have reviewed the value of Incident and Problem. When we start to talk about the value of change management some might suggest that this process is a ‘must have’ as it seeks to control the successful implementation of changes to minimize any potential impact on the business.
Not that I had this problem but did you ever pass a test where you scored 99% and someone asked “what about the other 1 percent?” Your rate of successful changes should be a value where someone is wondering what that missing percentage of failed changes is made of.

The reality is that an output of the change process could be incidents. Some might suggest that the percentage of incidents caused by changes could be as high as 80%. This could be many unaccounted for incidents
To be consistent with the previous posts if we were to look at the costs from an internal IT perspective what we would want to focus on would be not what the cost of implementing changes is, rather what the cost of failed changes is. In other words incidents as a result of a change.

Ok, I know you are thinking to yourselves, this is a bit of a stretch. If I was the change manager what is the benefit of showing what I cost IT? If you are asking this you are right on the money. This metric drives the incident and potentially your service desk teams to ensure that your changes are updated accurately as frankly they want the cost to be the result of someone else. It is in their best interest to associate any incident to a change correctly to show where the cost came from.
Let’s look at an example:

Note: these numbers have no value other than to show mathematics you can apply to your organization
Priority
Volume
Duration (average)
Total Duration (minutes
1
100
4hrs
24000 mins
2
200
8hrs
96000 mins
3
700
24hrs
1008000 mins

Staff
Salary/Year
Cost/min*
People
Total Salary
Tier 1
50K
.40
10
500000
Tier 2
75K
.60
10
750000
Tier 3
100K
.80
10
1000000



*Based on 40hrs/week and 52 weeks per year
If we were to suggest that:
Each priority 1 incident required the following:
          ·       2 Tier 1 @ 0.40/min = 0.80/min
          ·     2 Tier 2 @ 0.60/min = 1.20/min
          ·       1 Tier 3 @ 0.80/min
Cost per minute = 2.80

Each priority 2 incident required the following:
          ·       2 Tier 1 @ 0.40/min = 0.80/min
          ·       1 Tier 2 @ 0.60/min = 0.60/min
Cost per minute = 1.40

Each priority 3 incident required the following:
          ·        1 Tier 1 @ 0.40/min = 0.40/min
          ·        1 Tier 2 @ 0.60/min = 0.60/min
Cost per minute = 1.00


So assuming that we have the following incidents as the result of changes last month
Priority 1 – 1 incident which lasted 3.5 hours Cost = 3.5(60)(2.8) = $588.00
Priority 2 – 3 incidents which lasted a combined total of 29 hours Cost = 29(60)(1.4) = $2436.00
Priority 3 – 7 incidents which lasted a combined total of 74 hours Cost = 74(60)(1.0) = $4440.00
For a grand total of $7464.00

While a 99.5% success rate is nice we would like to be in a position to quantify even if it only pertains to the utilization to IT resources.

In my experience one of the challenges of keeping the closure codes updated is tying the incidents to the changes after the fact. In organizations which are not reviewing incidents, problems and changes regularly you may see that your change success rate is fairly high despite the fact that the incidents are not decreasing. By relating the incidents to the according change you can at least improve your reporting, begin a strategy for improvement, which if nothing else improves value.

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


Monday, 26 January 2015

Showing Service Management Value: Problem Management

One of the prime functions for problem management is to ensure we reduce the number of incidents which re-occur. This sounds like problem management would be an easy sell but in many organizations that is not the case, why? Well, to begin with when we look at the initial value that problem resolution brings to service management we are typically looking at statistics. These stats unfortunately may have not the best spin with regards to their optics. In other words they just don’t have that “wow factor attached to them. This is primarily due to the fact that they are presented to leadership in terms of volume. The truth is problem investigation might take much longer and when we look at “last months problems” we see a low volume of issues being worked on. We might see that last month the problem manager worked on 4 problems and maybe resolved nothing. Doesn’t really blow people away when you start to compete for attention with incidents that are restoring critical service and has potentially hundreds of incidents over the same time frame which are resolved.

Let’s leverage the example from the previous post

Note: these numbers have no value other than to show mathematics you can apply to your organization

Priority
Volume
Duration (average)
Total Duration (minutes
1
100
4hrs
24000 mins
2
200
8hrs
96000 mins
3
700
24hrs
1008000 mins

Staff
Salary/Year
Cost/min*
People
Total Salary
Tier 1
50K
.40
10
500000
Tier 2
75K
.60
10
750000
Tier 3
100K
.80
10
1000000

*Based on 40hrs/week and 52 weeks per year
If we were to suggest that each incident requires the following:
2 Tier 1 @ 0.40/min = .80/min
2 Tier 2 @ 0.60/min = 1.20/min
1 Tier 3 @ 0.80/min

Reduce re-occurring incidents
As anyone can attest to, when you have an issue with any product more than once your patience begins to dwindle. Business customers are no different than any other consumer. Aside from a reduction in the number of incidents each month there is also an improved customer experience.
Even if we were to make a simple Incident reduction in priority one incidents by 10% we would be left with 90 incidents. Providing that nothing else changes the total duration (in min) would be 21600.
The cost for this would be 2.80(21600) = 60480.00 per year which is a savings of $6720.00

Improved first call resolution
Increasing first call resolution allows you to reduce the escalation of incidents to other support teams as well as improving the incident duration and improving the customer experience. As you may remember from the post regarding incident ROI we had several costs associated to escalation of incidents.
Let’s say that we shot for a 10% reduction in incidents though problem, eliminated the need for calling Tier 3 and cut the need for Tier 2 in half  1.40(21600)= $30240.00 which is an overall savings of $36960.00 from the original 67200.00 for the priority 1 incidents if nothing was done.
If you were to take that back to the people reading your reports your small amount of problems start to show high levels of value.

Some activities will attribute to first call resolution or a reduction in incidents which may not have a quantifiable amount. For example if you were to have access to a knowledge repository where people can source out information for themselves rather than emailing or calling the service desk allows people to answer their own questions. Quite often they are doing this now on a personal level each day. So why not position the knowledge that you capture to be shared, where appropriate, to your business. Positioning yourself to plan ahead you should be able to track activity and maybe even usefulness so that you will be able to quantify the data being leveraged in these areas for future ROI on knowledge records.

Again doing nothing will ensure that no improvements are made. Start small, review what you’ve done and communicate that you are doing it.

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


Friday, 23 January 2015

Time Well Spent - Top ITSM Blogs

There are plenty of places to get your fill on service management content. There are some larger sites such as the ITSM Review, analytical outfits and course vendors, however I always like to visit a few blogs which I can get a more personal experience.

Here are some of my personal favorites in no particular order:

Great blog from across the pond by James Finister. Really enjoy the SIAM content here


A great place to get an honest assessment of what is going on from Rob England

Another staple of any ITSM diet should include a visit to Barclay Rae’s blog always full of sound advice

Always full of well-rounded information, I check into Greg Sanker’s blog regularly

Kengon always has really good input and sage advice for all things service management

Mika Salo is able to explain content easily with a wide degree of topics

For all things Business Relationship Management this is a must read for sure

In tight economic times a trip to Daniel Breston’s blog to get a dose of “Lean” is just what you need

This site has a wide variety of contributors who have a wealth of insight and information

No collection of ITSM writers would be complete without a visit to Stuart Rance’s site – let’s face it

If IT Governanace is what you are looking for Mark Thomas great information to read

There are many more, please feel free to share them with me


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

Thursday, 22 January 2015

Showing Service Management Value: Incident Management

Whenever you are talking about making any improvements to service delivery the key question is going to be where to start. Part of the improvement process is to identify what to improve upon. Most organizations will outline that the 'buck stops here so this is one improvment objective to look at - Value. Granted, Incident management in itself isnt a 'value add' process however I decided to start here since many organizations already are doing this on some level.

In another career lifetime I worked with a person who said that every minute counted, he said that if you added all the lost minutes together you could produce unimagined results. He usually followed this up with “time is money”. While he may not have been a positive mentor in the sense that I learned how to improve customer service I did learn something from him. Every minute counts.

Keep in mind, calculating the return on investment isn’t always going to be down to dollars and cents, minutes and hours. In some cases there will be areas which are going to less quantifiable like customer satisfaction for instance.

For some quantifying what a service costs will present at least two issues I can think of right away.

     1. That you won’t be able to quantify the cost of your services, and in the seemingly endless search this initiative will lose traction and fall off the radar altogether.
     2. Because of number 1, you decide to leverage values which have been deemed as industry standards. The trouble is when you are asked how you came up with the values and answer “industry standards” your audience may see this data as inaccurate or a guess at best.

So how do you proceed?

To begin with, if you do nothing you will achieve nothing. Doing something even if it appears insignificant will have some impact. I suggest by starting with what you already know. What it costs for you and your team to manage incidents.

Here is a simplified example:
Note: these numbers have no value other than to show mathematics you can apply to your organization


Priority
Volume
Duration (average)
Total Duration (minutes
1
100
4hrs
24000 mins
2
200
8hrs
96000 mins
3
700
24hrs
1008000 mins

Staff
Salary/Year
Cost/min*
People
Total Salary
Tier 1
50K
.40
10
500000
Tier 2
75K
.60
10
750000
Tier 3
100K
.80
10
 *Based on 40hrs/week and 52 weeks per year

If we were to suggest that each incident requires the following:
·       2 Tier 1 @ 0.40/min = .80/min
·       2 Tier 2 @ 0.60/min = 1.20/min
·       1 Tier 3 @ 0.80/min
The total for all Priority 1 would be 2.80(24000) = 67200.00 per year

What if we were to enable other teams in a way to reduce cost? Let’s say that we were to eliminate the need for a Tier 3 person at all for incidents 2.00(24000) = 19200 savings!

Alternatively if we were to reduce the average outage time in Priority 1 incidents from 4 hours to 3 hours it would look like this  2.80(18000) = 50400.00 per year – that’s a 16800 dollar savings.

Now I appreciate that these people are not working on these issues all the time but what we are looking at is identifying where our costs are associated. We may currently escalate all priority 1 incidents to our Tier 3 support as in this example, however after looking at the costs we may decide that there are better ways to do things compared with “we have always done it this way and it seems to work”.

The 30 people we have in IT are not likely to change as a result of reducing incidents however we should be in a position to re-allocate them to other work accordingly. In most cases putting particular skills to work in areas where they are used in a more cost effective way.

What an exercise like this really illustrates is where you can make some improvements or where any automation could help to reduce your costs.

 

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








Monday, 19 January 2015

Showing Service Management Value

In tougher economic times many organizations will start to assess the value of the pieces which allow them to operate. A challenge for service management is to not only show the value that they currently bring to the company but the continued value that they can provide in regards to delivering services.

The term business value can be interpreted in slightly different ways however for the most part it speaks to the ability for an organization to realize its business outcomes. Typically this is done through financial means but might also be in other less tangible ways such as customer satisfaction.

It would sound sensible enough so why aren’t more organizations doing this? The reason is that service management has to understand how services are supported through their lifecycle and a detailed level. Basically, who is doing what and when?

In my experience we ‘think’ we know how this is done until we start to take a real close look. This is where many of these initiatives can fall off the rails so to speak. We need to look at this type of work as a continual service improvement activity. There should be iterative goals associated with this type of work as well as an understanding that we will likely find out that we know less than we thought about how the services are supported.

With the ‘how we support service’ as a foundation, the next step will be to address what the cost of delivering services are.
In the lifecycle of a service there will be many people who play a role though the various support pieces we have outlined above. In some cases teams will manage particular functions, while others will manage them all.  The trick is to understand to what level teams contribute to activities so that we can associate a cost to that delivery of service. From there a strategy for cost reductions can be outlined and then actioned.

Small improvements can add up. Think about it in these terms:

If we looked at the current state and saw that we had 1000 incidents last year which had a total resolution time of 6000 hours. If we could cut that by 10% we might be looking at a savings of 600 hours in its simplest terms. That’s 15 work weeks for one person to do something else more productive. 

Over the next few posts I will speak to a few processes and where they can specifically address the value that can be added.

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




Thursday, 15 January 2015

Access Management and Auditors – Don’t Fear the Reaper

With the start of a new year many people are focusing on what lies ahead for 2015. In cases such as the previous quarters audit we are looking backwards to see how we did. Sadly when we mention auditors in any capacity people get a sense of unease in the pit of their stomachs. I on the other hand look to this time frame to not only reflect on what went well and not so well but to also learn for these experiences. 

One area where people may have challenges with regards to audits is in the access management space. For a moment think about how your organization manages access management as it pertains to your applications.

IT organizations basically manage the way that access is granted to key systems through three activities:

Onboarding – A person is starting new position or role and access is granted via a manual process, or automated with tools and may be verified through a “source of truth” authority such as SAP.
Changes / Modifications – A person is modifying position or role and will require different levels of access which again may be done manually or again automated through a toolset
Offboarding – A person is leaving a position or role in one way or another and the termination process drives the removal of access either manually or through tools

For the most part validating the onboarding and offboarding (joiners and leavers) may be simplest to define.
“Gillian starts on Monday and will need access to application x to do her work” (Onboard)
“Desmond has quit, remove access” (Offboard).  

It is the “Changes / Modifications” component that may need to be tightened up from a process perspective. The managing of users and roles across the enterprise, especially large and diverse ones, can be quite complex when there is no underpinning process to govern it.

For example, let’s suppose we have an employee who works in Business Unit “A” and is moving to work in Business Unit “B”.



Now think again about the way your organization handles changes or modification in access

When people change roles does your Access Management process discontinue all access from role A and then grant access to role B in a seamless way?
How is access to roles validated – the dreaded “just mirror John Smith” can create major access issues
Could lingering access from Business Unit A follow this person to the new role?
Are there segregation of duties concerns in the role access that we should be concerned about

You really need to ask yourself if your overall Access Management process is checked in a regular time frame (quarterly, annually)? I can already hear some people saying, we have an automated tool that handles all of this. Just because it is automated does not mean it is working or still valid. The process governing how the tool works should be validated just like in the situation above.

Remember finding gaps in the process and mitigating risk shouldn’t be something that is discovered as a result of an issue. Regular process checkpoints should allow you and your organization to proactively move on these before they become issues. This is why your auditors should be your trusted advisors in the sense that they are looking to ensure that you are protecting your corporate ass(ets). You shouldn’t be concerned with what your auditors find, rather it is what they don’t find that you should be concerned about.

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


Monday, 12 January 2015

Sieving out the Issues to Make Lasting Improvements

I seem to find answers to questions in the strangest ways. The other night I was playing with Lego with my son, well maybe he was playing with me. At any rate I was looking for a particular part and I was unable to find it in the big pile of Lego on the floor. As it turns out we also have a storage unit which has the built in functionality of a sieve. It works pretty well; you dredge up pieces and shake out what you need based on size. Using this thing I was able to filter out a large majority of the pieces I didn’t need to find the ones I needed more easily.

When we talk about gaining clarity in our ability to make lasting service Improvements we could look at them in a similar light. What tends to happen from time to time is that we want to know what all the answers are before we look for them, much like looking for one piece in a bucket of thousands. In our effort to prefect how we search for the answers we may hesitate or delay that search until we think we are doing it right. The trouble with doing this is that sometimes we take that much longer to take action on an initiative or in some cases never do them at all.

Much like with my Lego, I may shake the sieve and still not find what I am looking for. However if I remove what I no longer need and keep shaking different results will present themselves. It will be far easier to sort through what is left for my answer, rather than looking through the whole thing.

In my experience I find that you need to look at the overall big picture of the service that you are trying to provide and focus on one improvement activity. While this critical success factor may have a few indicators we are still only processing a simple amount of data through our service management sieve. Once we get some consistency on the results, the inconsistencies tend to become more apparent. From they were will be able to make a strategy to make some type of improvement.

Make sure that as part of the strategy that we have a timeline to perform another shake to ensure we are still on track. Consider a quarterly review, as this will allow some data to collect as well as having enough information to make an assessment. If the timeline is too quick we may not have enough data to support an appropriate decision. Depending on your organization you will know what the right size is for you.

Make sure to share the results with your stakeholders so that they also know where we are making improvements as well as potentially offering some suggestions or input.

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