It takes a drawing to see how the roll-out plan of an ERP implementation and the stages of commitment go hand in hand.
Building further on last week’s post about Daryl Conner’s 8 stages of commitment, I forgot to tell that there is another good use we can make of this model. Now that we have checked the phases and thresholds against the stages of social architecture, it’s time to see how they can be a guideline throughout our projects.
In the below drawing I have attempted to match the 8 stages of commitment on the typical project phases of an ERP roll-out.
Some remarkable conclusions can be made when we look at that drawing:
- The phases of project setup and design are both below the disposition threshold and the level of commitment we can expect during those phases goes no further than contact or awareness (reality check: I have known this to be true in my world). Needless to say that unawareness an d confusion are quite common in this phase as well;
- It takes a prototype to cross the disposition threshold. You need to be actively building something and designing an organization around it to create understanding. A negative perception is often the risk we run – certainly when we are in the first rounds of organization design (reality check: organization design is an iterative process – so that’s OK);
- It takes a drawing like this to realize that the very phase of testing is what tips the organization from the acceptance phase right into the commitment phase. It looks like the action threshold is reached in the middle of the messiest phase of an ERP project! There is a wake-up call in there! (reality check: Strange enough, this is a phase where organizational change practitioners go numb, thinking they have nothing to add to the ‘boring test sessions’. What they fail to see is that this is where people make a fundamental decision to commit to the project or not.) The truth is that we have nothing to add during test sessions. Rather, our added value is in distilling evidence and ‘sense’ out of these sessions. Ultimately, this is done by process simulations from end-to-end with all the major participants involved (reality check: that awkward moment when people in the same room become aware of the “silo” they are living in).
- The real adoption does not come from testing. This rather happens during the deployment, when we take the time to test the processes on the floor: are we physically fit to perform the processes we have been designing and building for? (reality check: the proof of the pudding is in the eating. Shopfloor is where you ought to be at that moment.). This is also the phase of cut-over or ‘go-live’ – and we should be aware termination is still an option for the project at this stage.
- The phases of institutionalization and internalization can only happen during the phase of post-implementation. Issue-lists, checklists of all kinds and procedures make sure that the new system and new processes are ‘policed’ throughout the organization. (reality check: The ‘police’ part is no kidding, because like learning how to drive a car the whole organization is running in conscious competence mode).
I can only conclude that it takes a drawing like this to get clarity on how the project phases and the stages of commitment interact. It also gives us a language to pinpoint the behavior and level of commitment we can expect during each phase. Try it on your next project and you will be surprised by the level of clarity you can derive from it.
