Source: https://www.odysseyis.com
Preface
In today’s world, technologies / systems are an integral part of any organisation. The key benefit of technologies / systems is that they enable productivity, i.e. make it simple and easy to do business.
For countless reasons, starting from cost cutting to enhancing security features to taking advantage of an innovation, organisations continuously run technology / systems project.
As change management professionals, we have often heard statements such as:
‘This is a small IT change. Does it really need any change management?’
‘It is only adding to new check boxes to the last screen. Change management has nothing to do with it’
‘This change is only for the enterprise IT team. No one else needs to know it. It requires no change management.’
It would be all fun if the program / project world were that easy. Unfortunately, it is not.
Key points for the sponsor to consider
Let me present the case for change management here. Alert! Do not confuse this with ITIL Change Management! I’m talking about organisational change management.
Point one, what is your definition of ‘small’? Is there a universally acknowledged definition of small?
Point two, how many business units within your organisation use that specific technology/ system? Have you spoken to them? Have they told you that they agree with you about the change being ‘small’ and, therefore, does not affect their day to day operations? Have they given you the go ahead?
Point three, have you checked how many of your clients use that system? Have you checked with them wither they think this proposed change is a very small one and doesn’t impact them? How does this change impact the customers of your clients?
Point four, do you have the list of how many processes are performed by different business units using that specific technology / system? Are you sure there will be no changes to any of these processes?
Point five, have you conducted an investigation of how many current process and training documents are there for that system? If they do not accurately reflect how the technology / system look in reality, how big will that issue become?
Point 6, what exactly is the small change that you have added going to do? If that includes a small process change, is that potentially a compliance breach?
Point seven, if the target audience see the changes and start to panic, and start to flood the IT Helpdesk / Service Desk, how will you manage it?
Point eight, will there be an inflight state, e. g. if the solution is rolled out on 1 August at 5am, what will happen to a transaction that was initiated but not completed before the rollout on 31 July at 5PM?
Point nine, if after the rollout, the system is not stable, how will the users escalate for support? Is there a RACI for it?
Point ten, how will you measure success? Let me make it clearer, there is a reason why you took the initiative to implement the change. How do you know if you have achieved it or not.
Last but not the least, if the new feature does not work and you have to roll back the solution, do you know how you will manage it? What are you going to tell your audiences?
The conclusion
If your answer to any of the above questions in ‘no’ or ‘I don’t know’, or ‘I haven’t thought about it’, you definitely need change management.
There is a reason why change management exists as a discipline/ profession / stream of work. And, if anything, it only makes a program / project successful and maximises the change adaption.
Comments