A few weeks ago I wrote a piece on a change management project we were working on entitled ‘my world, your world…systems led change and why it fails’. I promised some solutions or at least some ideas about how to resolve this type of issue and a number of you have reminded me that I have not been true to my promise, so here goes!
Language: Those of you from an IT world will have immediately reacted to the last sentence in thinking about UAT, whilst those without that background will have read it as written. IT folk and business folk speak a completely different language and for this process to work, there needs to be clarity about what is meant in both environments. Build a lexicon of language prevalent in the specific business world and IT application being deployed and be ruthless in any meeting where new language is added to make sure that its explained and added if appropriate. Monitor the adoption of both sets of language carefully and embrace / encourage it when it happens.
Iterative development: Before we all get excited and start talking about the relative merits of ‘agile’ versus ‘waterfall’ (for non IT folk, two basic methods of system development and implementation), I’m proposing an approach which has greater interaction throughout the development phase…so that users can start to see and play with the new system at a very early stage. If we bring the system in its barest form to the user and show them how it’s built, eventually familiarity will overcome fear. Once again, every opportunity that the user has to access the system means a moment which doesn’t require intense and often not vey effective communication! Seeing really is believing in this instance.
Managing exceptions. For those engrained in a business process for a long period of time, their life is ultimately about managing exceptions. As with all of us, the standard becomes routine, the exceptional becomes noteworthy. Unfortunately this mindset has an impact when thinking about new systems / and resulting process change…too often the exceptions take centre stage and there is enormous effort made to try and include these in the new design with little audit as to the materiality of the requirement. For the change consultant, being able to manage this carefully but robustly is critical. Agreeing on some materiality thresholds upfront should be an early activity with strong sponsorship from the appropriate stakeholders.
I’m sure that there is nothing very new in what I’ve proposed above and would love to hear from you as to other successful methods and processes you’ve used.