When you hear the words ‘they’ll never go for it’, the root reason is usually fear of change more than the financial cost Sure, cost is invoked as the reason that a change won’t be considered. ‘The Cost’ is the pat answer even when a change makes financial sense.
The real reason is more often the fear of change. You will never get to a serious cost and savings consideration for a change with a change averse decision maker. Yet you must overcome the fear of change in the person who approves the project go-ahead.
“That is a good idea.
It is also a new idea.
Therefore we must fear it.”
Lothar of the Hill People
Change Aversion Foundations
There is a solid basis in fact for the fear of change. Change, particularly infrastructure change, is a source of disruption. Disruption means people cannot do work the way they normally do, if they are able to work at all. The reduced productivity comes with loud complaining. While IT is generically blamed, IT knows that the root cause was an infrastructure change. Non-IT decisionmakers usually learn that the outage was from an infrastructure change. They don’t remember the specifics, but they do remember the disruption resulted from a change. Hence, the fear of all change that kicks in when considering a proposed new technology.
Every IT group inherits the legacy created by their predecessors in the decisionmakers’ minds of changes gone bad. A decision maker new to your organization might come with embedded memories of failed IT changes that happened in their previous organization. The inherited legacy means that cost is usually a handy justification for avoiding change. Since fear of change is the real issue, that means cost numbers will not be accepted and will be dismissed until the change fear is handled. This reality demands preparation to call out the fear of change. Addressing the change aversion must be done in addition to speaking to the cost.
Handling Change Aversion
When you hear the words ‘they’ll never go for it’, the root reason is usually fear of change more than the financial cost. Sure, cost is invoked as the reason that a change won’t be considered. ‘The Cost’ is the pat answer even when a change makes financial sense. The real reason is more often the fear of change. You will never get to a serious cost and savings consideration for a change with a change averse decision maker. Yet you must overcome the fear of change in the person who approves the project go-ahead.
Addressing change aversion requires being ready to share, in layman’s terms, the preparation steps taken to avoid disruption. You must be ready to speak to these points before a cost discussion will have any effect.
- What is the testing and simulation done before implementation?
- How many users are at risk from a change failure?
- Can the implementation be done progressively from a smaller to larger group?
- When would the cutover happen?
- Would the affected users be disrupted while the implementation is happening, and for how long?
- What is the rollback criteria and plan? How long would a rollback take?
An IT group with a track record of careful and therefore successful changes lowers the change aversion. Having an automated and established change process makes change aversion less of a barrier to presenting costs that will be considered. A group might not have that record of successful change. Since successful implementations are invisible ones, getting credit for succeeding with minimal pain is difficult. Failures ae remembered. You must be ready to address those memories..
Global Change Aversion
Some organizations oppose all change, whether it is IT related or not. It’s not just the presence of Windows 98 workstations and NT servers connected using Novell network cards. It can be a broken service door or bathroom used instead as a storage closet. “It’s been that way for years’ may be what you hear. Sound extreme? Sadly, it isn’t. Usually it is attributed to the owners/managers being ‘so cheap’.
If you came to IT to use technology to make an organization better, then you’re in the wrong place. No matter how virtuous the organization goal, frustration will be your lot. Leave. Really. You won’t be doing IT there. You’ll be curating technology which is dying. Don’t let your career die with it.
If an organization is hiring you and you clearly see these signs of embedded, change-adverse stagnation, just say ‘no’. For globally change adverse organizations, it isn’t just IT that doesn’t change.
‘But they want me to make changes’. Fair enough. New leadership may indeed want to make changes. At least you’ll have company in the change-seeking leader who hired you. You had better be well-compensating for the rock breaking that will probably be required.
Case study: Don’t Change ANYTHING
The president of a medium size manufacturer and distributor hired me to replace the current infrastructure at its four locations, each running independently The locations were basically a collection of home computers loosely (and dangerously) tied to the internet. Internally hosted email and a CRM from a company that had closed eleven years before were the primary applications. The accounting was the PIC system, which had last been updated 21 years before I arrived.
Such outdated technology demonstrated a need. The president’s backing seemingly indicated I would have support for change.
I soon saw the signs of unchanged facilities in disrepair. The big tip off was that the president answered to his father, who was the owner. The absence of changes in the non-IT portions of the business reflected the father’s change aversion. Dad’s reluctance was enforced in the form of the controller named Betty, who had the owner on her speed dial. She definitely did NOT like change. She placed a $100 purchase limit on all IT purchases. All other purchases required her approval, which trumped the signature of the president. The $100 approval trigger required enough of my, her and the president’s time for each purchase that the administrative cost of each purchase was about $81 a transaction. For a $101 purchase, that administrative cost was a hefty organizationally imposed surcharge.
Yet I accepted the challenge. With extreme effort (mostly constant paperwork), I was able to tie the sites together into a managed infrastructure, complete with a VOIP phone system. So my work succeeded in producing an infrastructure that was a substantial advance for the company. Technologically, the network was about four years behind the current average level. The ancient CRM and the even more archaic PIC system were untouched and, I had learned, untouchable.
I had used nearly three years of my career in the quest.
I had a skilled system administrator join me in the quest. He was a Sancho Panza to my Don Quixote. He had the good sense to move on to a less change adverse company. In his first year with the new organization he was able to do more with current technology than I accomplished with the hard-fought developments in three years. He also moved up to greater responsibility and compensation befitting the experience he developed in that year coupled with his innate talent.
The lesson learned was knowing when to go. From prior jobs I was accustom to resistance. That wasn’t a problem for me, The structural global change aversion to everything was. It could only be overcome by constant and Herculean effort to bring about minimal change. Cultivating paperwork skills to bring about outdated technology wasn’t why I went into IT.
Don’t let this happen to you…..