We often hear the words “change management” as an adjunct to reliability efforts. Yet, if one is to trust reports of reliability effort failures and abandonment, or reversal / devolution to earlier methods (or lack thereof), something must surely be going awry in the way we attempt to do things.
Change can be good, and it is inevitable, but too much change at the same time overwhelms personnel. A new approach to data input into the CMMS or EAM requires training and a little time for old (and usually inadequate) habits to get reformed. If management simultaneously modifies a whole list of other things, the chance of success in implementation suffers a considerable negative impact.
We are all too aware of the existence of resistance to change. “Better” must be demonstrated and proven before wholehearted adoption can take place. And criticism along the way will likely occur. The arguments of “bad faith” and “you’re resisting the change” usually point to bad implementation (key word would be usually: some people will just reject anything new out of hand).
As an example, I am reminded some 15 years back of the arrival of a software package for vibration-based condition monitoring. One of the (or perhaps just “the”) first operating on a Windows platform. It was pretty. It was easy to use. But its failings lay entirely in technical contents (or lack thereof): you could not do (at release) what had been common fare with the DOS version. As a matter of fact, I’m not entirely sure the final version could either, but that’s another story. Comments with respect the technical deficiencies or missing functions brought annoyed replies implying “resistance to change”. Was that the case? The passage to Windows and its GUI were good, no doubt. An SQL database was also a much needed improvement. The price to pay was high: the loss of technical contents needed to properly assist the analyst proved contentious for a long time.
The problems encountered while managing change often arise from a lack of understanding (or even caring) of the needs of all parties involved in the execution of the mission (production, maintenance, other). Things work out better when all parties are consulted BEFORE an initiative launches, and that means all parties at all locations of an organization (the needs, or the level of change, may differ considerably). When scepticism arises or when questions are asked, one needs to confront them head on, with pertinent answers.
Bottom line: enthusiasm and the embrace of movelty may be formidable drivers, but if the homework has not been done to convince others, support their needs and address their concerns, reliability (and other) initiatives may fail, with regressions, dismal results (in ROI terms), or simple failure to launch properly.
© 2007 by François Gagnon