What is the resistance to change ?

A good colleague posted a question on LinkedIn asking for an opinion of the barriers to change….here is my reply

More often than not Business Process Analysis is pushed to the back of the project agenda, almost an afterthought once the change is being implemented that the business process will have to change around the project goal. This is a sure way to consign the project to either fail or not complete on time purely because you begin to reengineer the business process for all the wrong reasons. Research indicates that 57% of technology lead projects are poorly scoped, and 36% of those have unattainable requirements. Process led projects have a 90% success rate suggesting that BPA is superior for getting process improvement requirements right.
The biggest barrier I’ve found is that BUSINESS process improvement is seen as an IT exercise, it has to involve an architecture element of some description in more mature organisations, must be seen to fit into the SOA environment and goal otherwise it’s not worth the effort. This is such a naive and counterproductive argument. Because of this, the business community feel distanced and alienated, and change is done TO THEM not WITH THEM.

I’ve taken Six Sigma to Green Belt level, and I’m currently undergoing certification for TOGAF, purely so I can learn what they are and why people insist on using them. So far, organisations believe that process improvement MUST involve some sort of dark art of science, when in fact it really encompasses common sense and a desire to question the status quo. Aligning a process to achieve an outcome the Customer is willing to pay for is not rocket science.

Typically, organisations are afraid of change. It goes deeper than “we’ve always done it this way and it works” because there’s an inbred fear of (a) change will make my life worse (b) change will expose me for the lazy sod I am (c) I can’t risk the change if it negatively affects my bottom line when it looks healthy enough thank you very much !
Any combination of those factors will create an instant resistance to a project.

Part of the problem is also really bad business cases being written for projects with a poor ROI realised. This is because you’ve got the wrong person leading the project. Bad business case = no budget

And talking of wrong people, I’m in the current client where a LEAN initiative failed because it was led by an idiot who (a) could not lead (b) did not have the necessary skills to communicate to stakeholders why and the benefits of the initiative.

There, I think I’ve hit the nail on the head…..COMMUNICATION.
It’s not the method, it’s the art of communicating why we need to change, and who we are doing it for (ie the Customer). There’s no one method that can 100% achieve change all the time, but if we break the barriers down for resistance with a clear message (and not a load of dumb motivational posters around the coffee lounge) then I reckon you’re half way there…..

Let BPM set the project agenda

More often than not Business Process Analysis is pushed to the back of the project agenda, almost an afterthought once the change is being implemented that the business process will have to change around the project goal. This is a sure way to consign the project to either fail or not complete on time purely because you begin to reengineer the business process for all the wrong reasons. Research indicates that 57% of technology lead projects are poorly scoped, and 36% of those have unattainable requirements. Process led projects have a 90% success rate suggesting that BPA is superior for getting process improvement requirements right.
Business Process Analysis should be the vanguard of any project, the first step to achieving project success, on time and in budget.
Why ? Read on.

A process cuts across both business and IT domains. It is agnostic of system specifics in the first instance (until the point where at the granular level, system level interaction and business rules start to be documented). When initiating a change project, consider modelling the business process first. This will ascertain the level of change that is required and dictate the scope of the project.
Too simple ? Let me explain.

Changing the process first will give you direct insight into the effort required to change the underlying technology and data.

If you redesign the system first without consideration for the business process it’s meant to support (yes, support. Technology is an enabler, it is not a driver) the chances are:

•    the system will no longer mirror what the objective of the process is, (see the Whitepaper Target Operating Models should be Strategic Operating Models)
•    the requirements were agnostic of the process its meant to support
•    the business may not operate as efficiently because the process no longer flows correctly and may ultimately mean more time and money spent on another badly implemented change (notch up another statistic for Forrester !).

If you redesign the existing process first:

•    it’s easier to understand the technology effort required to make the new process work, and ultimately define the scope of the project, its requirements and tangible benefits
•    the business case will become stronger because there is a definable process which can sit behind it in support of the figures you produce for the budget. Without modelling the new process first and any associated impact study (such as a capability analysis or human capital study) it will hard to reflect the true cost-benefit of implementing the change.
•    it may even prove that the change will give no benefit whatsoever, or worse, make the process more inefficient or reduce the ability to cope with work volumes