Monday, 29 July 2013

WORN - Write Once Read Never? – The Importance of Knowledge Management


I am far from an expert on the subject of Knowledge Management, however I regularly see the capability of what is possible based on the level of information we have available as well as what cannot be accomplished when we reach a knowledge roadblock. Knowledge is power, as the saying goes, but how is that power wielded? More often than not we find ourselves in a knowledge deficit while buzz words such as “Big Data” are floating around.

This topic came about, as most do, on a Monday morning coffee discussion amongst some colleagues. Much of the talk was around how we didn’t feel we have enough information to improve the customer experience.
·         Where is this information which we seek?
·         Does it not exist at all?
·         Is it in a repository somewhere in a SharePoint site?
·         Is it stored locally in someone’s mind and never shared?

I am not sure how many organizations share in this mode of thought, but do many have a custodial way of curating the information that they currently have? Everyone knows someone in their organization who believes that if they have the market on the knowledge stores they are invaluable and effectively irreplaceable. Unfortunately I have seen this cycle repeat itself too many times. That person leaves without the brain dump and we start over. Sadly in some cases we say “That will never happen again” and we end up right back in the same place.

First we really need to identify where we already are on a knowledge maturity scale. What do we have now and where is it? Knowing that, we should be able to formulate some type of strategy to get a process in place where one may not currently exist. We need buy-in from the powers that be. Really without that we will be doomed to repeat the same failures. 

Next we need to identify what is in scope for our knowledge policy and how do we ensure that the information in it is valid, current and usable. We need to ensure that this policy is adhered to so some roles will need to be clearly defined to ensure we stay on task. And that the information stays current and accurate

While there are many benefits, having this accurate information at the fingertips of the Service Desk at the very least allows improving first call resolution. Faster turnarounds on escalations for support teams where they may be known issues or even in some cases from information that can be shared with customers directly from a knowledge portal of some type

Many policies used to have limits set on the amount of content that could be stored in a time when storage was a constraint. This in effect was the check and balance against what information was created, stored and updated. Now the sky is the limit with larger than life storage capabilities locally and in the cloud.

In the beginning there will be lots to do, I won’t lie. It is likely that without any previous policy that you will have many knowledge records which are duplicate (or more) in nature, so wading through the mire may take some time – so keep it simple and have a defined simplified scope. Apply this and educate all facets of your knowledge management policy to your IT teams, PMO and business units where applicable.


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






Monday, 22 July 2013

Unlike Wine, Problem Records do not Improve with Age

I recently met up with a friend who is a Problem manager, and as practitioners do they need to vent about one issue that they are facing in their organization. We started talking about a Problem record that they had open and how it seemed it was never going to be closed off.
Digging a little deeper, and sensing that this was going to be more than a one Guinness discussion, I asked why it was still open.
“You know…the root cause of this issue is still there but the workaround is holding it together, in fact, the customers don’t even think that this is a workaround, they think the app is supposed to function this way.
I motioned to the bartender to get the next pint going….
Over the next while I learned the following about this problem:
·         The application was OTS (Off The Shelf) which in that form contradicted some processes which the business had used for years
·         The IT project manager was instructed by the business stakeholders to have the application modified to fit their current process
·         Before the launch there were several issues identified, however, the business did not identify them as critical so the application was rolled out on schedule.
·         In the first weeks of sustainment it was identified that there were more than a few “glitches” which were identified. The sustainment team made a list of the issues and created known error records in an excel spreadsheet and passed them along to the operational team.
I know what you’re thinking… first, wasn’t this a discussion about Problem management? And second there is a whole lot more going on here than Problem management issues.
The answer is “Correct” on both counts. What if I also told you that the application we are talking about was launched 3 years ago?  Here’s where this changes things a bit

The application was OTS (Off The Shelf) which in that form contradicted some processes which the business had used for years – the original OTS was so bastardized that the regular releases we not followed impacting vendor support
The IT project manager was instructed by the business stakeholders to have the application modified to fit their current process. The people responsible for this deployment have moved on to other challenges in other companies
Before the launch there were several issues identified, however, the business did not identify them as critical so the application was rolled out on schedule. The defects that remain, have been in existence for 3 years
In the first weeks of sustainment it was identified that there were more than a few “glitches” which were identified. The sustainment team made a list of the issues and created known error records in an excel spreadsheet and passed them along to the operational team. These issues are the problem records that have been opened
This is why the customers think the application works this way, for the most part it does. This lends to the following challenges:
·         The application experience is bad as there are workarounds where the defects have existed since roll out
·         The ability to correct the defects is impacted by an inability to move to new releases from
·         Lack of vendor support
·         Concerns that these fixes will make things worse – loop back to customer experience

Whether or not this problem can be fixed at this point or not is the least of concerns. In fact closing the problem off with a review of why this happened is very important. This review should be held with your key business stakeholders, PMO, IT Operations.
In addition to addressing the issues(s) as they exist, it should also be decided on what activities should be investigated to prevent an issue of this type from happening again.
This level of CSI allows the discussion point for improvement, but the “doing” part still needs to happen. Otherwise you may be faced with a problem record that is open for over 1000 days




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, 15 July 2013

IT and Business Alignment – Request Fulfillment – Your Window Into IT


In an effort to ensure that we are providing the customer with an exceptional service experience we strive to improve within IT. We might review the problem process to ensure the reduction of recurring incidents; in turn we may review the metrics of the incident process to ensure that we resolve critical incidents in a timely fashion. We may also review change management to make sure that we are reducing changes which are impacting services negatively.

However how consistent are we at reviewing the one process which faces the customer – request fulfillment. There are two perspectives for this review. From the customer and from internal support resources

From the Customer perspective

Typically the Customer sees the interface of the Service Desk as the single point of contact for IT. Requests go in and services in some capacity are provisioned. The review of the effectiveness should look at the effectiveness of this interface.

·         Is there a single place to satisfy the customer needs
·         Is there any type of self service capability to get information, answer questions or make simple requests
·         Is there a catalog to choose still other more complex services which may require approvals due to cost or security
·         Is there a way to interact with the people in the IT department in some capacity

Even in the simplest state there are always ways either directly or indirectly of navigating the system. Whether it be through automation or knowing someone who can “hook you up”.

Scenario

The CEO and an HR person are in the elevator one morning when the HR person sighs, “my New Hire report hasn’t been provisioned to my phone, I guess I will have to call the Service Desk yet again…”
The CEO sees the dismay on the HR person and replies “Not too worry, the Service Desk always gets things done right away!”
As the Elevator arrives at the HR person’s floor they say as they exit “...if you’re a CEO it probably does”

What is illustrated here is that in some cases there may be a flag for urgency to have a certain person(s) as a VIP. While there may be reason for doing this there may also be significant draw backs

From the IT Support perspective

The function of request fulfillment is to manage the lifecycle of the service request. This process can have huge volumes of work associated with it if it is not automated. It is important to review the process regularly to see where some streamlining activities can be undertaken to further improve not only the customer experience but to identify where IT work can be automated to free up valuable IT resources

·         Leverage your metrics – what are they telling us about the speed of service

·         Review the requests at close, are there inefficiencies from escalations to multiple teams
·         Vehicles for engagement – how is this done? Email, phone, IM, Social Media – what makes sense for our customers
·         Communicate within IT – what is working well for us as a business unit and what is not. Where can we improve as a whole for service delivery

Scenario

While there is no budget at the current time for a new Service Management tool, the IT Operations Director had decided to leverage the metrics from his teams to identify the cost associated with delivering certain requests. Her plan was to illustrate that the cost of the tool in next years budget would be outweighed not only by the cost of the manual work being completed (quantified by hours spent) but also being able to cut the average completion of those requests in half (customer satisfaction – dollars not as quantifiable)

At the end of the day taking stock of how we fulfill requests for our customers is a good start. Leveraging the tools we have in place to measure how we do this will allow us to make judgment on how we can improve the service we provide our customers

Follow us on Twitter @ryanrogilvie

Monday, 8 July 2013

Event Management – Often Used yet Overlooked

Given the organizational need for technology it would be a safe assessment that infrastructure and applications are monitored in some capacity for perfomance. So why is it that this piece seems to be “off to the side” when we are discussing Service Management.

Since Event management is part of Service Operations one would think that in a journey to provide exceptional service this process would have the same level of oversight that lets say, Incident management does. There should be a consideration on providing service to our customers from an "end to end" approach. This would include proactive monitoring to reduce the impact and volume of incidents

In short, Event management, is monitoring your infrastructure or applications to notify you if something “bad” is happening or about to happen. It also provides you the opportunity to understand what 'normal' looks like and be able to generate a baseline to measure against.

One of the primary challenges you will face is that because it is an activity that is done in the background it may not get the visibility it deserves. Depending on the organization we may also see that monitoring may only be utilized by infrastructure teams to look for simple 'up and down' alerts. 

Whether you are at the early stages of monitoring or an advance stages you should be leveraging these alerts to actually improve the delivery of services. These alerts are only going to be as good as the improvements we allow them to make through improvement initiatives.
Here is an example:

Application X has the following infrastructure
What do we know about Application X?
John E User uses the application Monday to Friday from 10am to 4pm

Infrastructure Team
  • There are two application servers with a load balancer
  • Infrastructure teams monitor this 24x7 and a threshold is in place to show that the application server is strictly up or down
  • Server OGILP02 has had some issues lately and has only had an uptime of 75% on average
  • The plan is to replace it but since there are is another taking the load the rush to beg for money isn’t quite there.

Application Team
  • The Application support team also monitors the devices from an application level
  • Server OGILP01 has shown some issues where when the load exceeds 80% some users experience performance slowness


None of these issues have been tracked in the form of an Incident or a Problem.

From the perspective of the IT department, the service is up and running and is looking pretty solid. From the business perspective, aside from some intermittent slowness the service seems pretty stable. For the most part life is good for John E User and the people at AnyCorp but what they don’t realize is that there is something bad about to happen.

Monday morning John rolls in to find that he cannot launch Application X. He calls his Service Desk who assures him that they will take care of this. They escalate to the Infrastructure team who indicate that they had an alert last night indicating once again OGILP02 had fallen over and required a manual restart. The Service Analyst, who is sharp as a tack, also calls the Application Manager. Their discussion outlined that the load on the application itself has reached critical mass and the application running on one server on a Monday morning is unusable. Both the Infrastructure and Applications teams independantly fix their issues everything seems good…. or is it.

What did we learn?

While the monitoring did tell us everything we need to know in basic terms we did not track it anywhere. By integrating these events within Service Operation processes we could:
  • Address Availability concerns by quantifying any known issues
  • Establish any capacity targets
  • Allow us to investigate root cause for OGILP01
  • Giving us solid statistics to raise capital for a more robust environment.  3 servers would allow us to provide high availability etc.

The challenge, as always, is to market to our teams why we need to make sure that all activities are tied together from incidents to problems to changes. This doies not always mean that our service management tools are limiting us. In some cases we do not have governanace over the process or have a lack of communication.

While there may be a little work in the beginning you will save that effort later.

It boils down to proactively solving issues before they are apparent to the business (which is why you have the monitoring in the first place oddly enough). Implementing this may require small steps, but there successes will enable you to show other teams that Event Managements has significant benefits.


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



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



Tuesday, 2 July 2013

IT and Business Alignment – Achieving Business Outcomes Together With Problem Management

This sounds more like a book title than a blog post and really this is a huge subject. So to quote myself “let’s keep this simple”

Like most everyone in a typical IT organization you are “invited” to regularly discuss customer alignment, in some cases there are even actual discussions with the customers. In other cases this is a discussion with disjointed IT functions in a crowded room with maybe a motivational poster on a wall. Despite which business units are present in the discussion, the key is that all functions should be working towards one common business goal(s). From a Service Management perspective we need to breakdown what is happening behind the scenes to ensure our ability to achieve success. One of these process that is quite often is discussed Problem Management. When this is brought up the brain trust in the room will nod their heads but this can be where things can slide off the hill. More often than not the question that gets asked is where to start?

To illustrate what Problem Management can bring to the table let’s walk this through an example:

Your Customer (Organization) - AnyCorp
·         One of your customer’s business goals is to reduce costs in overtime across all units including IT.
·         While you leverage Incidents, currently do not have a formalized problem management process.
·         Your IT Operation support team has an 8 week on-call rotation.
·         This Team currently gets called out regularly for an application issue which requires someone to restart services to get the error to clear.
·         Each call out is billable to at least 1 hour.
·         Each week this is called out (after hours) at least once between the hours of 6pm and 9pm local time.
·         This is escalated to 2 calls per week at every quarter end on average.

·         The impact to your analyst is minimal as they see it, and they get a few extra bucks in their pocket for the minor interruption.

Assuming the average call outs, this equates to 55 to 60 hours of on call per year for these escalations.

This may be time that no one is even noticing…. Except your customers, whose expectations for service has degraded to a point where there is an expectation that the service in question will have particular challenges.

Forget about the downtime outage costs, the overtime costs. This cost (which you may not be able to quantify) is priceless!

Enter the Problem Manager, or the person who will help facilitate the process.
After some discussions with the Operations Team who has been dealing with issue the following facts surface:
1.     While the analysts dealt with this issue they did not see it as a major problem
2.     The analysts were not aware that each other were creating and closing these application incidents
3.     Reporting was not set up to “look” for these types of Problems
4.     Since there was other on-call overtime allocated to the team, this expenditure did not throw any flags
5.     Discussions with the application team responsible indicate that they were aware there may have been issues with the latest release but have not heard of any issues from anyone on this until now


Here are some of the underlying themes:
We need to stop the assumption that we know what the customer wants.  Work with your Customer
·         Regular touch points with business stakeholders should be held to ensure we are hitting the mark on service

We must stop assuming that the left hand in IT knows what the right hand does. Communication is Key
·         Having regular meetings within IT to discuss issues which may be impacting customer service should be held. “How can we help each other help the customer” should be the theme.

We need to align IT to help the customer achieve their business outcomes. Work Smarter not Harder
·         Work with the business to know what the business outcomes are and align IT goals around them

Fine tuning underlying Processes (in this example Problem Management) should be kept simple. See above
·         See where areas for improvement from a supporting process standpoint are

This example is fairly simple in nature but it shows what can be accomplished if you can look at the big picture. In some cases just improving your communication skills and simplifying the way you work will enable you to find the low hanging fruit and improve the customer experience.


Follow us on Twitter @ryanrogilvie