We have all heard these before, whether in a change advisory board meeting, a go-no-go or some pre-change implementation gathering—statements that make us cringe and laugh all at the same time. Unfortunately, despite the mild humor they provide, we repeat them over and over at our own peril in some cases. Here are a few of the common ones I have heard over the years, with ways to address them in lieu of uncomfortable laughter.
“This is a quick 30-second change.” – The implementer says this as though they are not sure why this change must even be tracked; typically the statement is followed by a shrug. The truth of the matter is that, if implemented incorrectly, this brief change could cascade into 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. Have a way to mitigate risk in your implementation plan either through a back-out or some form of roll-forward support if backing out is not an option.
“No user impact” – While it may be believed that there is no impact to users, did we fully quantify if that is the case? For example, while the network outage does not impact the site in question as it is scheduled “after hours,” we should notify them that their site will be down and phone service will not be available overnight. If the business is planning to have people stay late for some activity, we need them to understand that there will be no network access and, in the event of an emergency, no access to the phone system. A communication plan would help in this case; transparency is important.
“Minor user interface change” – Translation: no training was provided. Despite what we may believe when we are implementing changes that impact the user interface, even something as simple as a color change may need to be at the very least communicated. In some cases we have had folks from the business as part of the project teams who have been in the modified system for a while, and even they may not fully appreciate the impact of minor visual or process changes. Depending on the clients, there may be confusion on what has happened, and may in turn drive up calls into the service desk. This could have been avoided with a communication and to some degree training, which may not be extensive but should have a level of reference material to avoid inflated questions to IT.
“No testing is really needed.” – This is one I hear fairly often in cases where the change seems overly simplistic. The question I often pose back is how you know the change was successful. The answer I typically will get is, “Well, you know, the lights are all on.” 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 any change review meeting, but that is the point—to bring things to the attention of others that 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. This should be made clear in the implementation plan.
“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. Routine or not, take care to spend the same diligence with this change as you would with any other activity to ensure success.
“But we have done this a million times.” – Nothing is flawless. Even with a solid standard operating procedure there could be other variables that could impact the change having an issue. If you have done this a million times and your failure rate is 1%, that means you have failed to successfully implement this change 10,000 times – think about it.
“This is such a small change, not even sure why we need to record this.” – This may be true, but 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 that 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 when correcting it down the road.
Aside from the phrases, here is some verbiage that also perks my ears at change review meetings, so I count them as a half
“Shouldn’t” doesn’t sound very certain. How can we ensure that this “won’t” happen, or have impact to people?
“Probably” sounds like you are running the odds at a racetrack rather than implementing a change. You need to have more conviction on your statements.
“Might” is like “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,” implies that not all the details are verified–get some proof.
The key here is to have a level of scrutiny under the details of these changes we are reviewing. While we may not foresee a particular facet of the change and account for it in the implementation, testing or communications plan, we need to know what we have reviewed is as complete as possible. Feel free to let us know what other phrases of disaster you have heard.