A little while ago when I wrote about The Monkey Parable, I promised that Iād write more about what I see as being the two most poisonous BPR dangers youāll face when attempting to re-engineer and optimize business process, at least from my experience of attempting to do so.

Well friends, the time has come. Join me, wonāt you, after the break.
āThis is How Weāve Always Done Itā
The first danger I alluded to in a not especially transparent way when I relayed the monkey parable to you all: we do it this way because this is the way weāve always done it.
This used to be an extremely prevalent problem in my organization. Less so these days thanks to a senior leadership team that specifically calls this thinking out and tackles it head on ā but even so this kind of thinking still exists where I work, and Iām 99% confident in saying it exists where you work too.
Essentially the thinking here is that weāve been doing something the same way for 20 years then there has to be an excellent reason for that, otherwise something would have changed long ago. The fact that nobody knows the excellent reason is seen as largely irrelevant.
So from a Business Process Management / Business Analysis perspective, how do you combat it? Itās all about perspective. Itās unlikely that any of the truly important processes in your organization are completed by a single person, and that makes perfect sense: somebody who shapes sheet metal to create a panel for a vehicle would be an extremely skilled craftsman, but that doesnāt mean they have the expertise to build a gearbox. Too often though we have too narrow a focus when we look at business processes.
Focus is only good if you know youāre focussing on the right thing, and to understand that you need to take a step back and take a more holistic view. Itās in doing this that you can start to break down those āthis is how weāve always done itā misconceptions, because they most commonly arise from a misunderstanding of the up- and down-stream impacts of the work a particular person is doing. If youāre looking for transformative change then my advice every time would be to get subject matter experts from every aspect of a process together to talk the whole thing through ā I guarantee youāll find waste, and probably lots of it. And if your process doesnāt start and end with the customer (in purest sense of the word), youāve defined it too narrow a way for this phase of your work.
Catering to the Lowest Common Denominator
āThink of the dumbest person you work with, and letās build a process they can complete with ease.ā
Iāve personally uttered those words in the past during sessions Iāve run as part of BPR initiatives, and I suspect Iāll do so again in the future. Getting people to think like this is fine, but itās a powerful tool and you have to be very careful not to misuse it.
If youāre talking about designing a user-interface perhaps, or discussing building automated error-proofing functionality into a system ā absolutely, letās make that stuff as intuitive (read: idiot-proof) as possible.
All too often, this gets taken too far and results in masses of waste and redundancy being built into business processes. If I complete a task that I then hand off to somebody else only so that they check every aspect of my work, thatās a problem. A big one. The company would be better off taking my paycheque every two weeks and burning it. They could use the fire to help heat the building, and they also wouldnāt have to deal with the massive attitude problem Iād develop through being part of a system that places no trust in the work that I do. The result of which is the problem becoming self-perpetuating: Now Iām not only disengaged, Iām not accountable for my work in any kind of meaningful way ā if I do a bad job then the person whoās checking everything I do will fix it anyway, so what does it matter? So of course I do a bad job, why would I bother trying to do anything else? āHa!ā say the powers that be, ātold you it was necessary to check over everything. We find errors in 65% of the tasks that Jason completes.ā
So how do you tackle this from a BPR perspective? Two ways. Firstly, you have to trust people to do the work they were hired to do. Thatās easier said than done sometimes, but as a Business Analyst (probably) dealing with people’s performance issues (whether perceived or real) and coaching is unlikely to be within your remit anyway, so why make it your business? If thereās one thing Iāve learned about people itās that you get from them what you expect to get from them. If you have low expectations and treat people like idiots, you get back poor performance. If you have high expectations and provide people with autonomy and, most importantly, accountability, then youāll get back the high performance youāre asking for. Quite aside from all that, if the ālowest common denominatorā that you have in mind when youāre designing a process really does require that a second person checks over everything they do then you should fire that person and start over with a new ālowest common denominatorā in mind.
Now that we have an accountable, high-performing workforce completing our process the second thing we need to do is allow for some mistakes. If we demand perfection from the output of our process then rework and unnecessary checks will almost inevitably be the price we have to pay within the process. Six sigma (which is what weāre all striving for these days, right?) allows for a defect rate of 3.4 parts per million, and that comes from the world of manufacturing where machines are doing much of the actual work. If your people-based process really expects that level of accuracy then my recommendation would be turn your attention away from increasing the processā sigma level and figure out a better method of handling expectations and dealing with the inevitable defects instead.