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!
Firstly, take the time you’ve allocated for business process discovery and quadruple it! There is an incredible amount of iteration required to ‘peel the onion’ in deeply ingrained processes. Sensible clients will realise that as much as this is a smart thing to do for the purpose of getting under the skin of the organisation in terms of processes, it also starts to socialise the prospect of change and create some trust. In my view, this is potentially a zero sum game…what you lose upfront in terms of time, you gain at the end in terms of user acceptance. Which brings me to my second point:
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.
- Incredible presentation from a great speaker
- Cultural traditions do not excuse banks rule-breaking, by Patrick Jenkins of the FT
Categories: Business process reengineering, Change management, Systems led change
Tags: Behavioural change, business process, change management, productivity, stakeholder management, Technology, uat, zero sum game
Inarticulate ramblings of a management consultant 
Dear Ben,
I’ve come to your blog from the pqubed site and have been impressed by some of your posts.
I’d like to contribute to your thinking on this subject, which I’m passionate about.
All your recommendations are very good ones but I would add an initial first step: identify the driver for change (which you have done), and identify who is responsible to make that change happen (it would not be a “system”, it will be a person with responsibility in the organisation that understands why this change is needed and the consequences of failure to change).
Then make sure everyone involved with the project understands the driver, its importances and the consequences of failure.
Do not think of the project as a “systems” project (this links to your thoughts on language). Every project is a business project. The business needs to update its tools, the project is there to help the business to do it. The system will not lead to business changes, the business will define the system requirements in a way that the system is ready for current and future challenges.
On the matter of development, I prefer to talk about implementation. Development is irrelevant, design and implementation are key. Can you design the system up front (because your users know the future process and requirements? or do you users require to see the system working before they can refine their thoughs about future state proccesses (new system requirements)?
Do you know what the business will look like after the project? Do you understand IN DETAIL how the change will happen (how an old process will change into a new one)? if the answer is yes and yes, big bang and waterfall may be appropriate. If not, thing about implementation approach, and that will drive the development and design approach.
Your post have made me think. Thank you
LikeLike
Dear Manuel, many thanks for your insightful commentary. In particular, I think your idea that one should take the system out of the conversation is very perceptive. In the same way that the discussion when administering medicine is less about the transmission mechanism than the content, a similar perspective on the system would be helpful.
I suspect that the reason why there has been so much focus on the system in the past has been that it has often acted as a barrier to change, specifically in the context of other parts of the enterprise architecture with which it needs to be integrated. But I get a sense that that is changing…your thoughts?
LikeLike