Most project owners and managers by now have recognised good Change Management as a crucial success factor for any systems implementation project. People talk a lot about it. However, looking around, I can’t see very much done about it, let alone done successfully. Why is that so?

I found that one reason is most people are aiming to high, when thinking “Change Management” and then quietly abandon a task that’s beyond their capabilities and budget, but they can’t admit it. In other cases, “Change Management” is seen as a fluffy intangible exercise for the weak at heart that mustn’t be allowed to take resources away from designing processes or programming reports and web dynpros. These people give it about the same priority as exhibiting pieces of art in the project room.

In both cases, “Change Management” is only seen as the really big thing few people actually are able to get right: engaging the whole workforce, big communication programmes, changing people’s mindsets, changing values, cultural change. This is all very important and may be necessary for some projects. However, this is usually the wrong level to attack change management for the average IT project, because:

• These issues need to be dealt with in a larger context considering the strategy and culture of the organisation as a whole
• This is nothing to deal with as an afterthought during a systems implementation without extra resources
• You need a dedicated expert in change and organisational culture to get it right. The average IT project manager will have a different focus in his or her skills set
• With a lack of time, skills and context, we find many managers talking about the magical things around change management, but to no avail.

Therefore it is much more sensible and effective to focus on the basics. If you get these basic right, you’ll beat 80% of IT projects already and if you don’t all the magic of motivational speeches and messing around with culture won’t makeup for it. In this blog we want to present a few straightforward and common sense steps you can take to improve on the change management side of your project without being a business transformation guru.

One thing that always strikes me is that project managers often suggest they are managing change, but cannot tell me what exactly the change is they are allegedly managing. If you want to mitigate negative impact and exploit positive impact an IT project has on all parties affected, it would seem common sense to start with the question “What exactly is changing for these people?”.

Therefore the easiest and most natural step is: keeping track of process changes
It’s as simple as that: create a table somewhere to be accessed by your project team and make sure that, if anything is going to change in the way users will do their job in the future, it is tracked in this table. Here is one simple example showing how we track changes in our cherished project wiki (based on confluence):

Then use the information collected to

• Get an overview of the process impact to see, whether it really makes sense
• Communicate (and maybe get approval for, if not yet done) process changes
• Show benefits counterbalancing any unpleasant changes people may have to get buy in
• Train those affected by process changes, where necessary
• Amend any documentation, including, but not limited to user handbook, auditing information, user helpdesk guidelines, etc.
• Create any other preconditions require for these process changes to take effect with minimal distress for those affected

• Getting the project team to keep track of all changes may require some change in attitude already. But here you are dealing with a limited group of people and a small change, and one you can easily demonstrate the benefits.
• There’s still some management skill required to use the information in the way recommended above, but to have the list of changes is the crucial first step and the results will definitely be better than the results of managing an unknown or vaguely known change