When I was younger my parents, teachers, etc. had explained to me that for the most part if you want to be really good at something you need to practice. I would imagine that most people have heard that at some point. Unfortunately from an IT support perspective in some cases we have applied this to operational activities where they really don’t belong.
An example of this is the implementation of a standard or routine change to correct an underlying issue. I know what you are saying, “…surely there must be a problem or some type of investigation for this issue though…right?”
Let’s look at this from this perspective. In an effort to improve service we (the IT organization) have decided to separate our change types by 3 types:
Emergency – are break/fix repair changes
Normal – requires more approvals, possible a CAB review and has high business impact
Standard– may have an automated approval, low risk and visibility
One of the areas of your reporting may provide data on the number of Emergency (break/fix) changes you have each month. This it allows you to align Incidents as well as identifying areas where you can continue to make improvements among other things. But let’s assume for a moment that an IT Ops analyst says, “We know we have an issue, we need to perform fix ‘x’ each week to keep the service up and running. Why can’t we just create standard changes for these, after all the fix is pretty standard, it’s just a restart of services.”
In my opinion I would suggest to avoid this, and here’s why.
First of all most people are naturally looking to have their “numbers” reflect an environment which is stable. To this analyst’s credit in this scenario they are saying that the risk is low and that we don’t want it to look like the sky is falling when in reality this is not the case. While I understand this position think about this for a moment. Ask yourself, once we take away the visibility of the issue are we really putting ourselves in a position to improve service or have it limp along? Here are the risks.
1. There may be some underlying infrastructure issue which we are bandaging each week that without the proper knowledge that it exists could in fact get worse. Further to that if we introduce other changes to this issue we could impact a deployment in ways we are unaware of.
2. The business may not be aware this issue exists. Allowing the business to know what limitations we have may position the collaboration between them and IT to make better decisions on a strategy down the road. The business may suggest that to correct this issue would not be worth the expense so continue to bandage the wound. They may also indicate that this potential performance risk is preventing them from taking their business to the next level and expenditure to repair or replace is in the business best interest.
This is why I like to see these issues remain as an emergency change type. There should be no secrets as it pertains to outlining the weaknesses which are present. After all they already exist whether we want to see them or not.