This is a quick 30 second change – the implementer says this as though they are not sure why this change must even be tracked. The truth of the matter is that if implemented incorrectly could cause a lengthy application outage. The old saying goes “what could possibly happen?” Better to be prepared with a plan if this does not go smooth.
No user impact – while it may be believed that there is no impact to users, how did we quantify that? We need to outline what that really works out to. For example - While the network outage does not impact the site in question as it is “after hours” we should notify them that their site will be down and phones will not be working overnight. If they had someone on site that was injured they may not have a way to dial out if the service is unavailable. A communication plan would help in this case. Transparency is key.
Minor user interface change – translation - no training was provided. Despite what we may believe when we are implementing changes which impact the user interface, even something as simple as a color change may need to be communicated. Depending on the business, there may be confusion on what has happened, and may in turn increase calls into the service desk. This could have been avoided with either a solid communication or training plan or a combination of the two.
No testing is really needed – this is one pops up more often than you would thhink. The question I pose back is how you know it was a success. The answer I typically will get is "well, you know, the lights are all on and the device is up." Even if the testing is simple, there is still a test to ensure it was successful. Track whatever it is in the change record. This simple test may be challenged at the CAB, but that is the point - to bring things to the attention of others what might not have been identified otherwise.
No real rollback is needed. This will work – while the steamroller of progress moves this into a production environment on a mandate that this needs to be implemented on a certain timeline, we need to ensure we have a plan established to mitigate any risks we encounter as a result of any issues should they arise. If we need to 'fail forward' we need to position ourselves to manage any potential issues.
This is a pretty routine change – even though the implementer is comfortable with making this change and has done it several times there is the element of risk and visibility to consider. If this change is truly “routine” it should be created as a standard or routine change, however you describe it in your organization.
But we have done this a million times – nothing is flawless, even with a solid standard operating procedure there could be other variables which could impact the change. even if we have done it a million times if only one percent fails that works out to 10,000 failed changes if you get the math....
It was an emergency – this change may have not been reviewed at CAB even. Despite users complaints to “correct this situation right away” there should be a process to handle this type of work. understand the difference between urgency and emergency
This was tested in Development; we are all good – First question. Are there differences in your non-prod and prod environments? Testing post implementation should always have the same rigor that the development testing has. While there may be components that can’t be simulated in all environments it is important to note and discuss them at CAB.
This is such a small change, not even sure why we need to record this – while this may be true – watch out, this is usually a red flag for issues. Such little regard for this was given that there may be integration points with other applications which were not even considered. This could be a Problem waiting to happen. If it is this small not tracking the change could result in issues correcting it down the road.
Words you really don't want to hear
Shouldn't – doesn’t sound very certain – question to ask is why won’t it? How can we ensure that this “wont” happen
Probably - sounds like you are running the odds rather than implementing a change
Might – (see shouldn’t) if the might is something that is getting business signoff (accepted risk) ensure the front line staff get the rundown of how to handle the situation
I think – similar to “probably” this implies that not all the details are verified
N/A and TBD – these are not even words, generally if these are in the RFC there is way more to be filled out before reviewing at CAB.
Subtle laughter - when people do this it could be a precursor to change issues....
These are a few of my favorites; please feel free to share any of yours
Connect with me on LinkedIn or on Twitter @ryanrogilvie
If you like these articles please take a few minutes to share on social media or comment