Wednesday, 30 December 2015

Improvements 2016 - Not a Broken Record


Every year I say that I am not going to have a post on the coming year, but I find myself starting to think about what 2016 will look like and here I am writing a post about it. If you were to look back year after year at posts of this type many of the same process centric activities keep popping up, much like dieting or quitting smoking. It sounds like a broken record. While those are still important, you might notice that the subjects I will be focussing on this year are more general.
 

Focus on Business
Do you know what your business does and what they are trying to achieve? In some cases we make assumptions that we know, or that we have a general idea of what they do. This level of assumption will not be enough in the year(s) going forward. We need to better understand the five W’s of the business. We also need to let the business know that we are interested in understanding their needs. Have we made a visible effort in building a relationship with them aside from the fact that we work at the same company.

Knowing what your business needs will better allow you and your team to target the delivery of service that they get. This should be an activity that you, as a provider, look at in the big picture sense of the word. In many cases you might find that these efforts seem segregated from the rest of the organization. This relationship should not be a secret; if it is it will limit its effectiveness. Be inclusive, and have people from various teams involved. Have the group open and not by ‘invite only’. Make sure that this is also marketed in a way that all teams are aware of this initiative; again make sure that this is not a secret. People should be excited about this.

Continual service improvement
Since the New Year is filled with initiatives to improve, it would seem like a ‘no brainer’ to have a continual service improvement initiative in this list. The trick to getting this started is to keep your improvement initiatives simple. Have a larger picture in mind, and build momentum off a few small wins in the beginning. While you might want to naturally have a large improvement which is more visible to people, you will be better served by having several small successes which lead up to something bigger. Each quarter review what you have achieved and don’t forget to celebrate the successes. This is important to building momentum.

Broaden your framework horizons
As more and more people are getting their heads around ITIL, we are starting to appreciate that there are other approaches that can complement and add value to daily activities. While we may use a particular framework as the, well framework for service delivery within IT, we should recognize that there are many other methods available that can add value. For me I will be looking at BRM, DevOps and COBIT, and integrating them into service improvement initiatives.

Networking
Whether it is online or in person, get to know the people in your community. This doesn’t always mean you have to go to a conference, although it might. Connect on social media platforms and get engaged in on-line learning and webinars where they are available, most of the information you can collect is free, and you can bounce ideas off one another to improve understanding. I spoke earlier about getting to know the business better but we can also leverage our colleagues in our communities to ask questions and see what they did in particular situations. Find yourself a ‘mentor like’ figure to give you some insight that you might not otherwise have. In turn you should also considering mentoring others as a way to further develop your community. You will find that this type of interaction will pay dividends on your understanding of how to better serve your own business.


In addition to these subjects I look forward to continuing to blog as well as interacting with you. 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, 21 December 2015

Problem Management and the Checkbox of Doom


An accepted drawback of being a problem manager, if you could call it that, is the fact that your efforts seem to go unrewarded when you compare it to the incident manager for example. It is possible that in a meeting where you are reviewing a recent major incident that you begin to daydream that you are in a large vaulted ceiling cavern. At the far end of the space you see the idol (root cause) you have long been searching for. Carefully making your way to the front of the room, negotiating over several traps you reach the idol which sits upon a stone pedestal. As an expert at situations like this you pull out a small sack and fill it with sand to match what you assume the corresponding weight of the idol is. With one swift motion you swap the sack with the idol and have it firmly in your grasp. It is then that the stone pedestal begins to drop and this sets off a chain reaction. You begin to hear a loud, deep rumbling sound which makes the hairs on your neck stand up. You know that it is time to escape. Running back through the trap area you make your way out into the corridor where behind you a gigantic bolder is crushing everything it comes into contact with. As you reach the end of the passage way you leap to narrowly avoid being crushed yourself.

Snapping back into reality you remember that problem management is not this dramatic, however, root cause analysis can have a similar cause and effect.

Think about it in these terms.

You have a business critical application that has a particular function which is not working consistently. While this particular function may not seem business impacting since it initially has only happened briefly a few times a month. It is now happening more often and for longer durations. To your knowledge there were no changes that could have impacted the application in a negative way but you can’t seem to get your head around how it was working before and now seems to not only be getting worse but it seems to go away without intervention.

After some initial investigation it appears to have been an oversight in a backend setting of the application. It is a checkbox that needs to be unchecked. Much like the dramatization above your excitement peaks as you clutch for the idol (root cause). Beware however that this could inadvertently trigger a boulder to chase you through the cavern.

A good understanding should be established on what that checkbox does and why the issue has arisen now. Don’t be too quick to swap the idol for the sand until you understand what the outcomes of that decision might be. While the checkbox might appear to be the root cause, the reason that the checkbox is impacting the system now is a deeper dive in to what is really causing the issue. Once you know that, you can get this tested out and confirm the results without fear of further impact.
 

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
 
 

Wednesday, 16 December 2015

Navigating Categories in a Sea of Others

Recently I was at a practitioner session where we began to talk about the categorization of work. Inevitably the conversation moved to what to do with a category or subcategory of 'other'. One of the participants in our group discussion had mentioned (in their words) “the extreme amount of time determining and vetting the categories and subcategories chosen.” They went on to say that their organizational culture operates in such a detailed oriented way that avoiding the use of terms like “other” is essential and was accounted for in the timeline for this project.

As a stark contrast there was another participant in the group whose organization categorized a majority of their requests in a particular bucket, but despite that they still had quite a few “others” to contend with. Since the others were not the main services they lived with the sea of others.

In my opinion finding a balance that matches with the organizations requirements is important. For the most part being able to actively report against them to improve in some capacity is necessary. The purpose of collecting this data in the first place is to use the information collected to make some assessments about what is happening in daily operations and then addressing them appropriately.

To achieve this level of balance we need to commit to those who will be consuming the output of collected data that all items which are reported on as other will be reviewed each month. After all, it is possible that our initial requirements gathering had missed something, or that a particular category might have been overlooked. Additionally as our organization grows we will have new services as well as services that will be retired so while the “others” need to be reviewed and added, we should also consider what to do with categories and sub-categories that are simply not used.

To accomplish this, a monthly report might need to be run to outline all the requests and incidents whose category contains some level of other. While some things may stay designated as other, others may be collected into a group where we can say definitively that these should be a particular category.

The reason that this becomes important is that while the vast majority of metrics are measured properly and being used by teams to look closely at what they are doing, the smaller stats are not being shared with the right teams who might be able to find out what they are dealing with.

In this example I am showing an overly simplified look at this. While the percentage of “others” in comparison to Application Support is not that large it is important to address what it is made of. After we expand this we reveal that there are security and HR escalations in there. Being able to provide this information to teams who are impacted will allow them to build their own improvement initiatives with reportable data rather than the “gut” feeling that they were dealing with in the past. This is only the beginning….
 

This sounds like quite a bit of work but if we want to display data in consumable and useful chunks we need to understand that these fields in our systems have a lifecycle just as much as the things they represent.

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


 

Monday, 14 December 2015

Starting the Improvement Engine

 “If you can’t do something right than it’s not worth doing” was something a stern professor had told me early in my college career. With this sage advice in front of mind, I dropped his class identifying that this method of leaning might not work out well for me in the long run. The trouble is that this mode of thought makes it way into everyday activities as well as how we operate to support our business, and in some cases we end up doing nothing. We have the “we would rather not fail, so we won’t try” mentality.

On the flipside I also had another professor who had a different perspective on the similar subject. His philosophy was “…that you will get nowhere until you take the first step”. Which was a completely opposite thought process from the other professor. The key, he outlined, was that while you get the ball rolling you also need to learn from what you either didn’t get right or what you might have missed.

We need to come to terms with the fact that we won’t get it perfect and how we will manage what is not.

This is where CSI (Continual Service Improvement) comes into play. While we may not get everything perfect we need to understand how the things we are working with impact the business objective that they support. After all if the improvements or work don’t support the business goals they are already going to be fighting for scraps at the bottom.

The next things to consider are what we are currently doing and where we want to get. This will likely involve some amount of reporting and communication on what we want to achieve. This type of gap analysis will give you a good sense of what will be involved in achieving the improvements you have identified in this step.

The key here is to keep this as manageable as possible. In my opinion I find building this into a routine works best for me. I will schedule the reporting on an activity or process from a months’ worth of data from the 15th to 15th. I do this so that any findings I have can be figured out and will accompany any month end management reports. For me this kills two birds with one stone.

This reporting will let me see if we still have gaps in the improvement initiative as well as whether we are achieving the goals we had set out in the beginning.

Overall you need to have transparency and inclusion of all stakeholders. This is where we may have some challenges. We WANT to have things perfect and we may have issue with showing any imperfections that may make us look as though we aren’t perfect. However if we look at this from the perspective of we have a strategy for handling the challenges that come our way, and support from all teams who are impacted we will be able to manage all imperfections that we come across and improve service delivery.


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



 

Wednesday, 9 December 2015

CMDB - Should I or Shouldn’t I?

Even as I post this, I am wondering what will emerge from Pandora’s box…

A comment that I received in a recent post was why I didn’t write more about the CMDB, or configuration management database.

Without a valid answer I replied back to the person and asked if there was something specific that they wanted to see. They wanted to know “should I or shouldn’t I implement a CMDB?”

In my experience I have seen this activity received with groans, excitement and confusion. In many cases all of these feelings have been exhibited during the course of the team discussion of “should we or not?”

The trouble is more often than not the reason that this even comes up is that through a tool implementation there is a component of service or infrastructure which is mapped against CI’s (Configuration Items) and this needs to be addressed in one way or another.

The problem with looking at this as an output from a tool is that there is little consideration on how this process or activity will be managed by the people in the organization. Remember the people; they are important in making this work. Far too often the reason that this process doesn’t work well (or at all) is that we only looked at it as a means to an end from a tool perspective instead of the perspective of people, process and technology

If I could offer some suggestions I would take it back it the beginning and look at the scope of what we are going to manage in our CMDB. No two organizations are going to look at this the same so I won’t tell you that there is a silver bullet on this one. In some cases you might want to look at your critical services at the beginning. Whatever you choose remember that keeping it simple will allow you to successfully manage this in the beginning which will produce some check in the ‘win’ column. If you attempt to boil the ocean it will likely work in your favor.

With a scope established you should be able to tie this in with your change management process. Keep in mind that like your change process there are activities in configuration management that need to be managed by people to a certain degree. Have some way to regularly review the CI’s for accuracy. This will not only allow you to see where they may be issues in the configuration management process but also if the inputs and output to this are also having challenges.

I can already hear you. “our tool does this automatically, so we don’t have to worry” while to a degree this may be true, trouble more often enough is that the tool will automate what we tell it to do and if we don’t fully understand what it is meant to do in the first place (process and people) we wont tell it the right actions to take. Which is why performing regular audits of your data is important to continually improve.

To summarize, think with the end in mind. Decide what you want to get out of the CMBD in the initial stages. Keep the scope small and don’t let the scope creep. Ensure that this process is tied into other service management processes so that where it applies the usage and value can be recognized acrros various areas within IT. Lastly, report on the success that you get as well as noting the issues and making corrections.

While a CMDB can be a daunting task, being pragmatic with how you look at this will ensure that you can achieve your goals.
 

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

 
 

 

Monday, 7 December 2015

Blame Free Post Mortems

In Latin, mortem means "death," and post means "after," in other words something that happens after death.

This morose definition lends itself to a less than proactive viewpoint on a critical improvement activity. However, how this is managed will make the difference to improve service through transparency rather than people holding back as a result of fear.

Recently, and part of the reason I am sharing this post, I ran into a friend who was in the middle of his holiday. After exchanging the usual questions and answers he ended up on the topic of work, as people tend to do. He was thrilled that he was off work this week as they were going over a post mortem for a recent outage his company had with one of its key applications.

He continued to tell me that there are very few things dreaded as much as the post mortem. People hate them so much that even during the outage they are already thinking about what actions will get them into hot water during the review. Imagine that?

He said that the post mortem at his company is lovingly referred to as “the blame game”. To add insult to injury he said that the team he is on, infrastructure, typically gets the lion share of the blame sine they aren’t as “inventive” with their explanations for issues and as such are not able to conclusively rule out that they aren’t responsible for the issue to some degree.

This should clearly not be the intention for a post mortem

By its very nature these post mortems should be an exercise in understanding, sharing and learning.

These principals should be applied early on. Involving all parties who were a part of the restoration of the service(s) as well as anyone who have a vested interest in the service(s) should be invited to the meeting to review as well as getting the document that outlines all the findings and outcomes. We need to foster transparency, and as such our culture should allow us to be open enough to be able to see where we can make improvements without worrying about who to blame.

After all the issue happened, and was fixed. That is the hard part, now we need to ensure that we can learn enough from this exercise to ensure we don’t repeat the same mistakes if we can avoid them.

Digging deep into the timeline will allow us to clearly see what actions we took, and why, at intervals throughout the issue. After all we may have experienced many different symptoms which led us to make particular assessments, which at the time seemed appropriate, but afterwards might not have.

Personally I avoid the use of the phrase ‘post mortem’ whenever I can and replace it with incident review. While you are making a step in the right direction to hold these reviews, if you are not fostering a culture of collaboration and transparency, you risk some details being supressed in fear of some form of punitive action.

Key components of a blame free incident review:
  • People involved during the issue
  • What contributing factors came into play during the issue
  • What was the impact of the issue
  • What did we learn as a result of this issue

Keep these activities in mind, take small actions as a result of the discussion you have after the incident and you will be setting yourself up for your team to make improvements on these issues rather than pointing fingers.
 
If you like this article please take a few minutes to share on social media or comment

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