Change is difficult. Like Newton's First Law of Motion, everything likes to be just as it is, highly resistant to any force that will change that state. Therefore, the fundamental obstacle that managers face in an organization is introducing a change. Quite often, IT managers face that inertia from business managers, and not without good reason. Business managers are interested only in the three letter acronyms -ROI, TCO, TCS and so forth. And not all benefits of IT can be monetarily quantified in that manner. The task of the IT manager, who is seeking to introduce a change therefore, is uphill to say the least.
Quantifying the business advantage
Numbers, graphs and charts are what business managers and accountants understand best. It is also something more direct and convincing than an encyclopedic volume written by doctorates. Your proposed IT change has to be quantified. There are of course the two usual suspects-short-term gains and long-term advantages. Which one needs to be highlighted depends on the scope of your change. Do not forget through all of this, that by introducing this change, you are seeking to enhance the business of your employer. Your calculations must allow breathing space. It must allow the business to catch up and recoup itself. The short-term expenses and losses if any needs to be small enough to make your accountants say 'that's okay, we can make that up easily'. Quite often, in the effort to please the accountant, a lot of expenditure is hidden away in the proposals.
|
Statements like 'let's implement open source because it is free' are too broad and sweeping to be made. Take all the facts into account and factor in all possible expenses. This way, your business and finance managers will retain their confidence in you when other changes are proposed down the line than if you hide them up and spring it on them as surprises along the way.
Educating the users
The biggest challenge to successfully implementing change is resistance from your users. People are inclined to prefer the 'old and set' ways than switch to a new one. They may also be reluctant to learning a new technology or a new way of working. Technology also brings in fear. Automation of the workplace was theorized to cause mass-extinction of jobs for humans when computers and later robots were put into production. But that didn't happen; nevertheless, the human fear element remains.
Your case for the project needs to allay such fears. You need to make sure that users get sufficient time to pick up the ropes of the new game and gain expertise before it all goes into 'production'. Your users will see benefits only if they feel proud to be a positive part of it. But a change in the business app you use or in IT policies you seek to enforce, even something as simple as a change in the way you e-mail, would affect your desk-user.
Continuance
Some change is transitional-like when you upgrade your infrastructure. Everything that you implement must be documented properly. This ensures continuance when your IT staff changes. Such documentation must include procedures followed too, so that problems can be found and rectified early during the next such
exercise.