Bpmmaverick’s Weblog

Bpmmaverick’s Weblog

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…..

Top Down vs. Bottom Up

Recently I’ve been reading a fascinating book called On Intelligence by Jeff Hawkins, the father of the Palm Pilot.

One section described how the brain and intelligence can be viewed via a hierarchy structure and it became immediately apparent that this could be translated to one of BPM’s age old questions:

Do we begin with a Top Down or Bottom Up approach when starting with BPM ?

I’ve attempted to paraphrase the book’s entry here with a BPM slant, but I urge you to read the book itself as it’s truly enlightening.

Trying to figure out how BPM works is like solving a giant jigsaw puzzle. You can approach it in one of two ways. Using the “top down” approach (EWPM) , you start with the image of what the solved puzzle should look like, and use this to decide which pieces to ignore and which pieces to search for. The other approach is “bottom up” (Six Sigma), where you focus on the individual pieces themselves. You study them for unusual features and look for close matches with other puzzle pieces. If you don’t have a picture of the puzzle’s solution, the “bottom up” method is sometimes the only way to proceed. Lacking a good framework for understanding processes, organisations have been forced to stick with the “bottom up” approach. This tasks is Herculean if not impossible, with a puzzle as complex as an organisational structure.

Imagine a jigsaw puzzle with several thousand pieces. Many of the pieces can be interpreted multiple ways, as if each had an image on both sides but only one of them is right. All the pieces are poorly shaped so you can’t be certain if two pieces fit together or not. Many of them will not be used in the ultimate solution, but you don’t know which ones or how many. Every month new pieces arrive in the post. Some of these new pieces replace older ones, as if the puzzle maker was saying, “I know you’ve been working with these old puzzle pieces for a few years, but they turned out to be wrong. Sorry! Use the new ones instead until further notice.” Unfortunately, you have no idea what the end result will look like; worse, you may have some ideas but they are wrong.

The puzzle analogy is a pretty good description of the difficulty we face in BPM. The puzzle pieces are process information and data that an organisation has been collecting for years. Each month, new statistical information, data or process is collected and analysed, creating additional puzzle pieces. Sometimes the data collected will contradict the data from another source, and because it can be interpreted in different ways there will always be disagreement.

Without a “top down” framework, there is no consensus on what pieces to look for, which pieces are more important, or how to interpret the overall solution. Our understanding of BPM has been stuck in the “bottom up” approach. What we need is a “top down” framework.

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

Welcome to the home of the BPM maverick and thought leader

Theo is a consultant and practitioner of a number of process analysis methodologies, mentor to Executives on strategic process issues and a thought leader in pushing the BPM boundaries to break new ground. Unconventional, often a loose-cannon, his ideas, thoughts and Customer focused determination have started to get noticed from international leaders in the BPM space.

Currently working for 2i Limited as the Head of Business Process Management, Theo hopes this platform provides an insight into his thoughts, skills and experience and hopefully challenge your views and perceptions on BPM and general Change Management.

Take a look around, then give me a call.