Methodology does not trump human nature

Methodology. An ugly word. When used alongside business process improvement, 'methodology' suggests that there is a logical approach, a preordained series of steps, a pretentious way of saying there is a method to fixing business process problems. Like a workflow for fixing your workflows. At a high level, I’ll concede that this may be reasonable, but get much deeper than “analyze, measure, improve, rinse and repeat” and the methodology is just a hack of a bunch of experience and skills (I hear the Six Sigma guys beating at my door already). A methodology when used without care can blatantly ignore human nature, organizational behavior, and sheer common sense. I prefer my methodology to be more a constructive generic framework.

Things get even worse when the eventual goal is a strictly defined, no nonsense Business Process Model and Notation (BPMN) map of the process. Any graphical notation for drawing ‘workflows’ that requires a 538 page PDF specification probably needs the support of an equivalently strict methodology so its developers don’t stray off too far from some form of best practice in drawing their pretty workflow diagram.

As we all know, there are many ways to actually handle the implementation of business process improvement projects:

• a business process management (BPM) tool to implement the workflow
• a suite of tools to draw, develop and analyze the processes
• a bunch of offshore software developers to produce some vaguely usable services for end-users
• some common sense guidelines for workers to help them guide the process better themselves
• any combination of the above

The reality of many successful business process improvement projects, independent of the implementation approach, is that the more methodology you try and stuff into the analysis and development of the ‘solution’ to your problems, the less room there is to maneuver when it comes to the actual reality of business processes: human nature and company politics trumps everything.

My proven approach (call it a methodology if you must) to business process improvement projects, (whether they depend on software development, business process management (BPM) tools, or plain simple task lists) is simple:

flexibility, iteration and communication

I unfortunately haven’t had the pleasure of re-engineering a process of 15,000 people, which likely requires some significant structure to making it all work. My experience is more for the 15 to 150 people processes, and to do them well often requires less methodology and more flexibility.

Think I'm completely wrong? Follow @consected on twitter and tell me!

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com