After listening to the Hacking Business Technologypodcast I was thinking a bit more about Problem Management.
Typically the discussion sounds like this:
IT Leaders: “We want to reduce incidents and improve service”
IT Support: “OK, we will look into that”
Wait for the deafening silence.
While all people in IT are looking at each other and shrugging shoulders they are already working towards this goal. The trick is that we may not have enabled them with the capability to actually achieve this goal.
Regardless if you have a formalized way at looking at problems or not you need to have the right components playing into problem analysis to actually be able to make the service improvements you are looking for. It’s like having a two or three legged table. It might balance for a while but overall it is not going to work as well as it could.
I like to look at problem management like a cocktail. For it to taste just right you need a myriad of ingredients. Here are a few of my favorite inputs and why.
Post Implementation ReviewsThere are two components where these can help you identify areas where issues arise. The first as it pertains to failed changes which cause incidents. I have said it before, sometimes the incident records and changes are not linked in a way that will clearly show continuity. So this documentation will connect some of those dots. Look at the ones you have from last week, or last month. What services are they impacting, what went wrong with these changes? The other post implementation review that should be looked at is as a result of emergency changes. If we need an emergency fix this also should also point us in a direction that shows where some issues lie. Particularly if we are doing “routine” emergency fixes
Critical incidents will happen from time to time, this is a reality. However making sure that we learn something from all of these issues is important. We should be asking the people who are in these reviews if we identified what caused the issue and what we are doing to ensure it doesn’t happen again. If we don’t know, or worse yet the issue was fixed by magic, we might want to see if this is something that we can dig into further.
Looking at “the numbers” we should be able to ascertain some basic form of trend analysis. Are we seeing an increase in the number of incidents, requests or changes? If so why is that the case? If we are seeing an increase in one of these there is a possibility that the others will see an increase as well as I pointed out in a previous blog post “The Yin and Yang of Incident and Change…”
Having a discussion on the flow of work within the IT organization will also allow you to see what challenges each other are facing. In some cases there are silos with the IT team which are preventing the whole to understand the challenges the parts are facing. It is possible that an infrastructure team is seeing an issue that could be addressed by someone’s expertise or experience in the application support team or vice versa. Utilizing the larger knowledge base will allow you to see things in a broader way.
Having similar discussions with your business will also allow you to see what you in IT may not see through your current reporting capability. There may be cases where apathy has prevented the business in escalating an issue. Another example is that we may not truly understand a particular business service we are providing and may be underplaying its importance from a priority perspective. All these discussions are important and should be had regularly. Whether you have a formalized role such as a business relationship manager or not you need to understand the services which you supply.