The Time Factor

As I am writing this we are about to shake up a traditional organization by means of an SAP implementation. Most of the times this is regarded as a pure software implementation: design the system, configure the system, test the system and roll it out. That is how most software engineers look at it and that is what traditional managers expect of it.

Only, with SAP it’s slightly different: since the software is supposed to administer the way you get your work done inside your organization it is quite instructive as to which standards, timings, methods and data you should manage from then on. Very soon you will find that it pretty much dictates your way of working – that is – if you want to get things done you better align to the ‘way of the system’.

I’ve facilitated about five SAP implementations before from the change management side and as I am embarking upon my sixth one I am starting to see the importance of the factor time. SAP brings with it a number of changes like: different working methods, different documents, a change in an organizational structure, a change in a procedure or a dramatic change of existing SLA’s (Service Level Agreements). Some of these changes are pretty easy to sell, but others a bit tougher.

In an earlier article I presented a framework for positioning the changes accoring to two dimensions: degree of behavior change and degree of WIIFM (‘What’s In It For Me’). I borrowed it from John Gourville (Harvard Business Review 2006). However, since this week I have a bit more clarity on how to use it.

As a starting point I make a big inventory of changes. There is no structured approach to doing that apart from keeping your ears open and being there when people start to worry about the future. This inventory always comes to the surface when ‘old’ meets ‘new’. Mostly a bunch of consultants and a bunch of dedicated business people work together in blueprinting sessions and design workshops. That is when these conversations happen and that is exactly when you should have your notebook ready. Soon you will have an inventory of changes.

Next, it is time to plot them on the Gourville matrix. As a consultant, you should resist the temptation to do this task by yourself. As part of the exercise you should ask the stakeholders (mostly SAP key users or process owners) to map the changes on this matrix. This is what Edgar Schein calls a ‘diagnostic intervention’. In other words: you are surveying the stakeholders but the dignosis itself is an intervention that triggers a change process: people are forced to start thinking about the changes in terms of ‘will we resist or not?’.

Finally, when all changes are plotted you are ready to prioritize the communication in terms of timing. ‘Rough spots’ and ‘Long Hauls’ will need a lot of context (i.e. why-communication) to settle in – and this takes time. The reason is simple: you are introducing a foreign element that will shake up the way things are.

So this is what I will be kicking off next week: harvest the inventory of changes. Having them plotted on the Gourville matrix and then get to the rough spots as soon as I can. People need the time to resist, to say ‘over my dead body’, to bargain and to come to terms with the new reality. Wish me good luck!