Monday, 24 November 2014

Why I Look at Reporting in Reverse for Service Delivery

A colleague of mine was saying that in a recent manager meeting her team came to the conclusion that they needed to implement (or rework) a particular process to drive improved service delivery. Their homework assignment for the next meeting was to outline what they thought was a good way to not only ensure that they were implementing something that would add value from a process perspective but was going to be sustainable in the long term.

My suggestions always include the use of metrics. After all, you will need to be able to measure what you are implementing and if you want to continue to be able to improve you need to show what a baseline for ‘today’ looks like.

I mentioned to her that when we do our annual HR goals planning we are expected to have SMART goals, so why don’t we have that same level of expectation when we are looking at improving service delivery. Quite often we just don’t think about it in the same context when we really should.

From a roadmap perspective think about what your end state should look like and then start to work “backwards”. I asked her what the largest pain point was. She said it was the rate at which service requests were being handled. On average they were able to resolve requests within 43 business hours. The expectation was that these would be resolved within 24 business hours.

Knowing where you want to be you can help filter out what metrics really matter as it pertains to the challenges you face. To start with she looked at “Average duration of incident by priority”, which seems like a fairly obvious p[lace to start.

Without looking through a sea of metrics she was able to spend more time looking at what was going on from a resolution perspective by priority. Right away she was able to see that the teams were handling the top priority requests really quickly. In fact they were being handled quite quickly. This is the first win. We are doing this right so make sure your teams are aware of this success! After some checking she could see where the longer duration issues exist and was able to dial into them with more scrutiny. Look to identify what is causing constraints on the workflow. It could be the number of escalations of requests, or that there was a lack of specialized resources. Whatever the slowdown might be there is a root cause to consider in your investigation.

Much like working on a problem record investigating the root cause for your request metrics will take some adjustments. The first, and likely most obvious symptom which is eating up your resources might be (yes, I am going to say it – password resets) for example. Once you have a way to address them you will need to look once again at the potential constraints and make further improvements where needed. At each stage you need to review the improvements you have made and celebrate them.

While you might not get to the goal right away, communicating with your stakeholders on the progress will allow you to share in the team’s success in improving not only the service delivery but likely in streamlining the way you are providing service

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



Thursday, 20 November 2014

Blackouts, Brownouts and Other Change Windows

It’s that time of year where we are looking forward to the change management holiday downtime, or are we? Depending on the rules around the brownout (or blackout) you may find that there are additional complications associated with them. Here are a few:

No formalized outage window
Depending on your organization you may have an unspoken understanding that people are away from the office and that changes simply aren’t done. The risk here is that without some governance over this “agreement” you may run into issues with your business units looking to take advantage of resources who seem to be more free time and asking them to just put in this “little” change. As we all know this lends itself to problems of its own, as little change have a way of doing from time to time. If there are complications there may not be the usual support resource pool to utilize for example which could impact your business more significantly that if this change was moved out to another date.

The pre window flood
In the event that your organization normally has high levels of operational changes, you may find that depending on the brownout window duration, you will have a larger volume of changes that need to be put in before the brownout begins. It is important to outline the expectations for the window as early as possible so that you are able to have more lead time to stretch the larger number of changes in over a shorter than usual timespan. If you don’t the risk you run is having a pile of changes which may collide the week before the brownout for example. This may cloud the ability to investigate issues should an incident appear with more changes which could be the culprit.

The post window flood
I have found that January can be a month with more than its fair share of changes primarily because of brownout windows. Some teams may push out implementations until the next change (or release) window and there may either be more changes in volume, or larger changes in scope. This can also complicate the ability to have successful deployments if it is not closely monitored.

Exceptions to the rule
Overall you will need to build in some flexibility to your windows since things still could break, and some projects which have high business impact are still pushing forward. Ensure that all teams are aware of the rules. Also allow for changes that no one even considered. There may be a need to do some change which does not fit nicely into one of the boxes above. Ensure that extra approval signoff is required to make sure that implementers understand the added risk of putting a change through during this outage timeframe.

The best plan is to communicate and work with your teams to ensure that you can regulate the flow of changes over the holiday season as well as ensuring that your business continues to experience the exceptional level of service it is accustomed to.

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




Thursday, 6 November 2014

Are You Managing Releases or Are They Managing You?

Depending on your organization you may or may not have a formalized release management process. You may be handling this though some other process entirely, the question that you should be asking is whether the releases are managing you.

How can you tell if things aren’t going the way that you want them to? Firstly you probably are pushing code into production at a rapid rate (someone might say that this is agile but if the end result is more issues that smiling faces on the business end you are probably doing it the wrong way.

If this is you or you are not managing releases at all the next question why not? Generally the answer you will get is that it’s either really hard to do or that its complex. That might be the case but it doesn’t have to be so difficult.

You can make it as simple as you want. Start out with a specific portfolio of what services you want to include in your release process – watch out for scope creep! Once you know what you are including you will be able to prioritize the release and generate better planning.

Get into a rhythm. Figure out what works for you and your business. It might be quarterly, monthly, weekly or more often. The key is to ensure that you can manage what is in the release throughout the lifecycle from planning to deploy in production.

The point of release is to ensure that you are integrating all components of people, process and technology across your organization to produce consistent results for each release. Being able to control the regular flow of releases improves the likelihood of business satisfaction with the end result.
In order to do this you need to make sure that you are validating progress in each of the stages including; planning, design, development, and deployment into production.

 





Here are a few to check at each stage (there are others): 

Planning
  • Make sure the development and operations teams are included in the planning
  • Ensure that any system requirements gave been vetted

Design
  • Ensure that the IT team has been notified of the upcoming deployment
  • Has all the business input been reviewed

       Development
  •        Is the Service desk ready for the upcoming deployment
  •        Have we reviewed all the deliverables to validate completion

       Deploy
  •        Ensure all the tests are finalized
  •        Have SLA’s been reviewed where they apply


       Overall before we get ready to deploy into production we should have a document which checks off and validates the following:
  •            What does the backup schedule look like
  •         What is the business continuity plan
  •             A completed network and infrastructure diagram for all environments
  •           Any security requirements have been addressed
  •            All of the hardware and software has been installed and a list of the assets
  •        Has the deployment had appropriate levels of communication
  •        Has training been provided where necessary
  •        Are staffing levels appropriate for the deployment from support including the Service desk and various tiers


Being able to address the simple questions will better position you and your teams to handle releases before they handle you.


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



Tuesday, 4 November 2014

Service Management and the Three Bears

Why is it that we seem to complicate reporting when it comes to service management? If we are really aligning to business outcomes it should be relatively simple, yet for some reason it seems that more effort goes into the reporting process than value comes out.

At a recent meeting with some like-minded people we were discussing this very topic. One person had mentioned that in their organization they were required to provide all reports in a summarized monthly document. When I asked what that looked like they said it was about 25 pages of tabular data with some bar and pie graphs thrown in. Literally all the reports summarized (seemed like a contradiction of terms). I asked them if it took a long time to pull together and they said that the system pulls it out and they do some editing so it really only took about an hour now that they had it down to an art form. What was more revealing was their department doesn’t really do anything with the metrics which are extracted. In other words the vast amount of data that was extracted is not driving improvement. They believed that while their teams wanted to improve they had no time to go through this “summarized” report.

Another person said that their problem was almost the opposite. They recently implemented a new service management tool which came with several canned reports as they tend to do. The leadership indicated that they should use those as they were simple and easy to read, and hey, they are already built and ready to go. They went on to say that while they were way quicker to go through than the previous organizations reports that they also had little value since they didn’t tie directly to their organizations operations and improvement strategy, if there even was one.

Much like the story of the three bears, there was a case of too much reporting, too little reporting and then there is the case where the reporting needs to be just right, which is where we want to live. To do that we need to ensure that we are measuring the things that will enable us to meet our business objectives. 

In the beginning start out simple, even focusing on one critical success factor with some KPI’s is better than blindly following some canned reports and far better than boiling the ocean with several reports with little meaning.

Once you have some measurable success you will be able to build on that momentum and continue on your service improvement initiative.

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