In the community of change management theory and practice, everyone likes to skirt around the inevitable challenges inherent to change management in IT. IT has a reputation both as a department and regarding the people involved, for a quirky and distinct personality with its own way of doing things and its own philosophies and practices both technically and dealing with business.
Until very recently, when end users became more technologically inclined, most businesses regarded their IT department as something to leave to its own devices, unless a major financial problem or some kind of malpractice came up. Most people never expected to understand the concerns and sciences that IT had to deal with, and felt that it was best left in the capable hands of those who understood it. This is less of a case now, as the role of IT shifts thanks to SaaS, and more people get used to handling technology more intimately. As a result, change management in IT now ropes in outsiders – change management professionals, rather than just telling the IT guys “do what you have to in order to solve these problems or lack of efficiency we see”.
So, how, as a change manager, must you approach IT, considering this department has a corporate culture all its own? Let’s consider this.
#1 – Forget Everything Lewin Said
I know this is hard to do, as even though the actual Lewin model is deprecated, his philosophies are still widely prominent in change management theory. That’s usually just fine, but for IT … not so much.
Lewin talked about unfreezing people as being one of the biggest problems to overcome. Well, IT people do form attachments to certain systems on occasion, but that’s rare. IT people are open to ways to make things more efficient and modern, so the first thing to do is worry less about selling IT on changes when the changes are justified.
#2 – Smaller Steps per Cycle
Something else to rethink with IT is that smaller steps must be taken, smaller changes per cycle. Making huge changes that take time can stall IT, and therefore stall your organization badly.
When it’s procedural or policy changes outside IT, bigger steps can be made at a time, with only minor, diminished efficiency. With IT, where technology is your backbone, handling changes must be in smaller steps, less abrupt.
#3 – Changes Outside IT
While you’re applying changes within IT, the ripples of change will branch outside IT, and affect the users of the technology IT manages. They may be small and less of an issue in some cases, but in major changes, this is one where changes passed outside the target department pretty directly.
In these cases, you’ll have to handle a little of Lewin’s freeze prevention in the passed on change, and you’ll have to factor in that the changes, when handled here, are a bit more training intensive and difficult than they will be for IT themselves.
I point this out specifically because in applying changes inside IT, less training and gentle handling is necessary for their personnel – they’re used to it. But you can’t let that go to your head, when the ripples of change hit people not inside IT.
So, change management in IT is kind of a two-pronged issue. Within the department itself, you have far fewer obstacles, beyond making sure baby steps are taken to prevent an organization from stalling. However, unlike many departments being affected by change, what you do affects other departments in a direct, traceable way, and you have to form a complete secondary strategy that’s more traditional to handle that eccentricity.