Thursday, 28 February 2013

10 Things You DONT Want to Hear at CAB

Each week, depending on your organizational setup, a group of vested parties gets together to review, assess and prioritize the upcoming changes. This advisory board is also known as the CAB or Change Advisory Board. Whether your organization has an official one or several “CABs”the following is a selection of some of the reasoning’s that I have heard in these meetings.

This is a quick 30 second change – the implementer says this as though they are not sure why this change must even be tracked. The truth of the matter is that if implemented incorrectly could cause a lengthy application outage. The old saying goes “what could possibly happen?” Better to be prepared with a plan if this does not go smooth.

No user impact – while it may be believed that there is no impact to users, how did we quantify that? We need to outline what that really works out to. For example - While the network outage does not impact the site in question as it is “after hours” we should notify them that their site will be down and phones will not be working overnight. If they had someone on site that was injured they may not have a way to dial out if the service is unavailable. A communication plan would help in this case. Transparency is key.

Minor user interface change – translation - no training was provided. Despite what we may believe when we are implementing changes which impact the user interface, even something as simple as a color change may need to be communicated. Depending on the business, there may be confusion on what has happened, and may in turn increase calls into the service desk. This could have been avoided with either a solid communication or training plan or a combination of the two.

No testing is really needed – this is one pops up more often than you would thhink. The question I pose back is how you know it was a success. The answer I typically will get is "well, you know, the lights are all on and the device is up." Even if the testing is simple, there is still a test to ensure it was successful. Track whatever it is in the change record. This simple test may be challenged at the CAB, but that is the point - to bring things to the attention of others what might not have been identified otherwise.

No real rollback is needed. This will work – while the steamroller of progress moves this into a production environment on a mandate that this needs to be implemented on a certain timeline, we need to ensure we have a plan established to mitigate any risks we encounter as a result of any issues should they arise. If we need to 'fail forward' we need to position ourselves to manage any potential issues.

This is a pretty routine change – even though the implementer is comfortable with making this change and has done it several times there is the element of risk and visibility to consider. If this change is truly “routine” it should be created as a standard or routine change, however you describe it in your organization.

But we have done this a million times – nothing is flawless, even with a solid standard operating procedure there could be other variables which could impact the change. even if we have done it a million times if only one percent fails that works out to 10,000 failed changes if you get the math....

It was an emergency – this change may have not been reviewed at CAB even. Despite users complaints to “correct this situation right away” there should be a process to handle this type of work. understand the difference between urgency and emergency

This was tested in Development; we are all good – First question. Are there differences in your non-prod and prod environments? Testing post implementation should always have the same rigor that the development testing has. While there may be components that can’t be simulated in all environments it is important to note and discuss them at CAB.

This is such a small change, not even sure why we need to record this – while this may be true – watch out, this is usually a red flag for issues. Such little regard for this was given that there may be integration points with other applications which were not even considered. This could be a Problem waiting to happen. If it is this small not tracking the change could result in issues correcting it down the road.

Words you really don't want to hear

Shouldn't – doesn’t sound very certain – question to ask is why won’t it? How can we ensure that this “wont” happen

Probably - sounds like you are running the odds rather than implementing a change

Might – (see shouldn’t) if the might is something that is getting business signoff (accepted risk) ensure the front line staff get the rundown of how to handle the situation

I think – similar to “probably” this implies that not all the details are verified

N/A and TBD – these are not even words, generally if these are in the RFC there is way more to be filled out before reviewing at CAB.

Subtle laughter - when people do this it could be a precursor to change issues....

These are a few of my favorites; please feel free to share any of yours

Connect with me on LinkedIn or on Twitter @ryanrogilvie

If you like these articles please take a few minutes to share on social media or comment



Wednesday, 27 February 2013

To Tweet or not to Tweet? Why Social IT for Service Management - Part 1


Depending on the type of organization you are working in, (and let’s face it - the demographic of its key decision makers) you may or may not have some form of Social IT. In discussions with some leaders around this subject you can almost watch them grimace as they avoid discussing it

To a degree I can get where they are coming from.  Having only recently dived into the world of social media I understand where there may be some misconceptions on what it is and what it can potentially do for internal IT purposes. Many people who I spoke with on this think that social media is more for external “marketing” uses. But consider this:

·         The average time Americans spend per month on social networking 6.9 hours . (source: DigitalBuzz )

·         1 Million websites are integrated with Facebook (source:Uberly)

·         23%of users check Facebook 5 times or more daily (source:Socialnomics)

·         56% of customer tweets are being ignored (sources: AllTwitter)

·         In 2012, 1 million accounts are added to Twitter everyday. (source: Infographics Labs)

·         There are 175 million tweets sent from Twitter every day in 2012. (source:Infographics Labs)

·         625,000 new users on Google+ every day. (source: AllTwitter)

·         Google’s +1 button is used 5 million times a day (source:AllTwitter)

There starts to be an expectation from your customers (the business) perspective on how we should be interacting with them. So it becomes clear that we need to make some considerations for this when we interact with the business or customers regarding Service Management.
In some ways your customers are already performing their own Social IT. Think about how often they will “Google” something to try and fix it before calling into the Service Desk. This in itself is its own commentary on the speed at which service is provided. To some degree you are probably doing this yourself. What if we were able to take that learning and apply it in such a way that a community of users could leverage the information?

This is where some grumblings from leadership may begin. “How do we do this, and monitor content that” you need to learn to walk before you can run.

Follow us on Twitter @ryanrogilvie

Friday, 22 February 2013

Incident Management – Kickin’ it up a Notch – BAM!

Since I had such a good response to the last post talking about issues I had experienced with Problem Management I started to think about what experiences I had with regards to Incidents and what knowledge I could pass on. A few months back I was discussing with a colleague who is currently at another company about what they were doing for IT Service Management and she mentioned some improvement initiatives they were working on and said “… and well you know, we already do Incident.”
She mentioned that there were some challenges with Incident but it really wasn’t on the radar for review or improvement since their leadership didn’t see many issues or concerns. She mentioned that while the process was pretty smooth there was always room for improvement and since the company had grown the service that was provided may not be what it once was.

I bumped into her again this past week and she said that they were going to take a closer look at incident as part of the ITSM process review and improvement initiative they had underway. It turned out when she went to the leadership group with her analysis of the current state of incident they were surprised. The perception from the top brass was that service was always quick and receptive, but as someone also pointed out it is mentally ingrained for people to go the distance for the company VIP’s and maybe that was where some misconceptions began. She said there were many areas that did not “make sense” anymore from an organizational standpoint and that to improve the other processes they were also going to rework Incident Management on some levels as well.
This can be an uphill climb, while you might think that there is only a few tweaks remember this process is the most recognizable to your customer base. Any changes might be like re-launching this process to your business or customers so it should be tackled in such a manner.

Whether it is a modified process or brand new here are just a few of the challenges I have come across:

Buy in and commitment. You need to have a solid plan before you communicate on what you are doing. You need a method to track the incidents, as well as a clear understanding of the incident process. What to do with incidents which are critical and ones that is not. “How do you know which incidents are critical?” You might ask yourself. This is where there needs to be an agreement on which services are considered critical to your business and which of those supersede the others (priority matrix). This will help you to determine the priority of issues you deal with. Depending on what tool or process maturity you have you may be able to automate this in some capacity rather than the service desk going from the gut upon creation.

The ability to detect incidents as early as possible. There are a few ways we can work to improve this situation. From a process perspective we need to take a look at the Event and Problem management processes if they exist. Is there something here that we are able to leverage, do the operations team monitor any environments and are there ways we can reduce double work to improve service. Getting these activities lined up can reduce the outage time and in many cases reduce the actual impact to our customers.

Convincing all staff to log Incidents. This is where we need to improve our relationships with our customers. From their perspective they just want something sorted out. They don’t want (and frankly don’t need) to jump through hoops to get things working again. There are 2 components for this. The first is that if the experience with the helpdesk is such that they don’t bother to log the issues we may not truly identify the scope of the issue and prioritize it correctly. There is also the way in which the escalation can be made to support. We may need to look at ways in which we can diversify the contact. How do the users want to communicate with us? We also need to make sure that our customers know that we are there to deliver an excellent experience, and to do that we have a process(s) in place. This level of communication can be handled by something as simple as a one-on-one personal connection through to roadshows, surveys, discussions, and social media.

Availability of information about Problems or known errors. There are many escalations each day that are known issues. If you are at a point where you are able to have a public repository of known issues where users can check before they escalate this will reduce calls into the service desk. In some cases the tool which generates the Incident will also have a place to view these documents. Put that to work for you.

The old saying goes you can only manage what you can measure. There is no need to over complicate this; doing so can be where you may have issues with reporting consistency. At the end of the day you are looking to identify the how well (or not) you are delivering services. In the beginning define, or redefine your top goals are and line up your metrics to report on them. As you get more mature in the process you will be able to enhance your KPI’s to make further improvements.

These are just of few of the common roadblocks that I have run into while working in Incident Management and there are plenty of others. Feel free to let me know which areas you have seen some issues.

Follow us on Twitter @ryanrogilvie

Friday, 15 February 2013

Problem Management Pitfalls – Areas where I have gone wrong

As part of the Service Management strategy, it was identified that you would implement Problem Management. Like any improvement initiative you are bound to have some roadblocks and shortcomings. These are some of the ones I have come across and what was needed to get over the hurdle or around the mountain.
Pitfall #1 - Ensure you have commitment from all levels in your organization
Using the example in my previous blog post The Foundation of a Service Management Roadmap remember the Senior leadership wanted us to get this process going without having any additional resources or funding. “More with less,” as you may recall. This mandate, while it has come from a place where you might just assume everyone is on board, may simply be the direction you are given and not signoff that everyone “gets” what we are doing. This is where you may need to leverage your service management colleagues to identify what level of understanding your organization has (or doesn’t have) so you can target your approach to getting everyone onside. You will also need to identify who everyone is. Keep in mind your IT support teams are the ones who you are looking to have an understanding of what we are doing and why.
Pitfall #2 – Problems are just big Incidents…Right?
Many people these days now understand how incidents work, so the misconception is that it will be easy for them to assume that Problems, while they sound similar to incidents, are the same thing. This issue can especially pop up if your Incident and Problem Managers are the same person. Comments like,  “This is confusing…what’s the difference” is a response I have often heard. Depending on the target audience, it may not really matter what the difference is. What needs to be communicated is what the function of Problem Management is – to avoid incidents through root cause analysis. And this needs to be communicated through the right audience. Your end users do not necessarily need to know or understand what happens. All they want is a great customer experience.
Pitfall #3 – Linking your Incidents to your Problems
While this sounds as though it should be simple, this may be more complex than you might think. This will depend largely on how you record and report on your Incidents. This may be where the single role of Incident / Problem manager may have the advantage. Since the same person is getting the output from the reporting, they will have a vested interest in ensuring appropriate reporting is complete. This may also impact the way in which incidents are recorded to provide good reporting statistics. If the Problem and Incident roles are separate the teams will have to ensure that they work together to record information that is beneficial to the common goal of incident reduction. In the beginning you might identify that there are some gaps in how you are able to report as a result of other processes, don’t get discouraged. This may lead to discussions on how we can address the maturity of other processes in the Service Management improvement initiative.
Pitfall #4 – We are still seeing incidents, doesn’t Problem management prevent this from happening?
Provided that you have gotten everything else right, you may still be in a position where your Problem Management is in ‘reactive’ mode. While ‘proactive’ Problem management may be just around the corner you may need to improve some other processes to help in your quest to iron out this last item.
These are just of few of the common issues that I have ran into while improving the Problem Management process in my experience there are bound to be many more. Feel free to let me know which areas you have seen some issues.

Follow us on Twitter @ryanrogilvie

Friday, 8 February 2013

The Foundation of a Service Management Roadmap

So you have decided to ramp up a few processes through a Continual Service Improvement (CSI) initiative. As part of that activity you have identified the current status of the following through a maturity review:


·         Problem Management

·         SACM – Service Asset and Configuration Management

Repeatable and Defined

·         Service Request

·         Incident Management

·         Change Management

The direction that you have been given from leadership is “to do more with less”. In other words, there is no money right now to do these improvements, but if we could prove out the value through initial actions we might be able to scrounge something up for resources or tools down the line.

The first thing that we need to do is to define “what is the scope for this phase of the CSI initiative”. This is critical because scope creep can spiral this work out of control. Keep in mind we are working with limited resources, and let’s face it, you aren’t dropping your regular workload to work on this so your time is precious.

The scope in this example will be to formalize the Problem and SACM processes. You might not have any resources right now, but that’s OK. We have already identified that these are currently ad-hoc. So step number one will be to formalize the process by putting it down on paper, as it was. The process documentation does not have to be complicated or pages long. What it does need to indicate is:

·         Who owns what within the process. If we are using people with existing ownership ensure that this has buy in.

·         What the process entails, steps and activities

·         Inputs and outputs of the process

Despite the fact that you will be working closely with some IT Stakeholders you will still need to keep them and your leadership informed on the progress you are making. This can be accomplished with weekly status updates to stakeholders. Include such things as timelines, successes and roadblocks

As we identified earlier, you don’t have any people who are solely allocated for this work, so we have had to user other resources from our more defined processes own them at the moment. A resource(s) from Incident Management will manage Problems and Change Management will own the SACM process. Remember the scope is small, your SACM could be 10 key services and Problem Management may be a weekly review with your Incident Managers to determine recurring issues.

As part of you scope you should determine at what point you will be ready to implement the next phase of your CSI initiative. Since we are still working under the premise that we are not allocated any funds (or very little) we can either say “after x months”, or at which point we are repeating the process with little effort, or a combination of the two. It will be at that point where you will begin the CSI process again.

You may find that you reach an point where you will need to allocate resources or implement tools. This is where you will be able to review the ROI on the processes you have implemented and be able to quantify the value they add now, as well as the increased value you can expect going forward.

Follow us on Twitter @ryanrogilvie

Friday, 1 February 2013

Incident and Problem Management – 2 Roles with 1 Person

I was recently asked what would be the easiest way to start up the Problem Management process using existing staff which was allocated for Incident Management. The direction from their Senior Leadership was "that these things are really the same anyways”. While there is a degree of truth to that perspective, this may be a perception that you are faced with more often than not, and may only be altered though results from your processes in action.
“Our Incident Manager(s) are really busy putting out the fires…”
It seems like the chicken and the egg scenario, but in reality as you are able to permanently resolve some of these recurring issues and help to stabilize your environments though Problem Management you will continue to have all these fires to put out. Don’t misunderstand, the first while is going to be hard work as you will be doing new activities while still reacting to all the incidents which are coming in.

How do I start?
Start things simple. Since your resource(s) are limited, keeping the scope of activities small is imperative. The one thing that you will need to make sure that there is clarity on where Incident ends and Problem begins. Since the goal of Incident Management is to restore service as quickly as possible this is where you will likely start. Once teams have resolved the issue we will be looking to determine what the root cause of the issue was. This is where wearing two hats can have some challenges. For example, while an issue may have been corrected through a restart of services, what we really want to figure out why the services required a restart in the first place.

Who can help?
Fortunately the Incident Manager has already built relationships with the support teams who work to resolve these issues, even better is the fact that what Problem Management is attempting to do is to lighten the reactive workload for them as well. So selling the process to them shouldn’t be much of a challenge.
What’s next?

While these different yet symbiotic processes are working to improve the customer experience, you may need to prove the value of Problem management before you will get real buy in on building it out with additional staff.(see Avoiding the wheel of solutions – Implementing Problem Management).

Until you are able to get to a place where you are able to separate the roles you might need to schedule time to be the Problem Manager. The key to remember is to keep it simple to start and target the top issues that you face each week. Reviewing the Incidents on a weekly basis with stakeholders often affords you the ability to step away from Incident Management and get a different perspective on issues which are impacting the business each week.

Follow us on Twitter @ryanrogilvie