The Myth of Micromanaging (with BPM)
I have to admit that the myth of micromanaging as a requirement of BPM is one of those things that just irritates me. Even more so when people in the ACM community foist that upon the BPM community, of which they are a part. Kieth Swenson’s blog, “Is Micromanagement a necessary part of BPM?” makes the case that it is:
Good BPM is all about detail and lots of it.
Wrong. Good BPM is all about the right details, and context.
Well implemented, a BPM diagram is supposed to be as complete as possible, that is, as detailed as possible.
Wrong. Complete is not equivalent to detailed. I can give you a complete picture of the solar system without any of the details of how each planet works. Abstraction and layering are your friends.
Have you ever heard someone ask to remove some of the detail from a process? There seems to be no limit to the amount of detail that one should try to include.
This is fundamentally a misrepresentation of what a BPM diagram is for. And good BPM consultants know how to deal with the objections for removing process details. Here are the proper questions to answer when something “can’t” be removed:
- Is it adding value to the end-customer? (not the internal person, the external person who represents revenue and profit) – if so, what is that value? Is it measurable?
- Is it adding value to an internal consumer? – if so, what is that value? Is it measurable?
- Is it removing waste, or avoiding rework?
- Is it required by regulatory or legal requirements?
- What bad things happen when this step/detail/item is not performed in the process?
- How is this captured/represented/dealt-with today? (pre-BPM Diagram implementation).
This is BPM consulting 101, folks, nothing to see here.
So What is the BPM Diagram for?
A BPM diagram is first and foremost, to ensure maximum understanding of the business process. In the case where a BPM diagram is to be executed as well, then the goal is to balance understanding with execution correctness.
Having a diagram “as detailed as possible” has never been a goal of any successful BPM project. This harkens back to the days of using a plotter to print out flowcharts that have no concept of notions like abstraction, encapsulation, subprocesses, pools, etc. – and ignoring all the advancements that good BPM suites have brought to the table.
BPM Isn’t about Mistrust
Worse yet, this proposition was set up with the idea that micromanagement is a sign of mistrust, BPM is micromanagement, and therefore by applying transitive properties, BPM is a sign of mistrust:
“Stop micromanaging. Micromanagement is a sign of mistrust. You hired them for a reason. If you don’t trust they will get the job done then by all means, either find people who you think will, or leave them alone to do their jobs.”
This is good advice for almost all teams, and certainly for knowledge workers. But isn’t micromanagement exactly what BPM is all about?
Seriously. I guess we could call the spell-checker in word processors “micromanaging” as they imply a lack of trust that we as knowledge workers, don’t know how to spell or hyphenate correctly. But I prefer to call it automation for the purpose of letting me focus more on writing (and, thank you to the spellchecker for finding several typos in this blog post, would that it would spot them all!).
BPM Isn’t About Micromanaging
BPM isn’t about micromanaging, it is about carving away the superfluous so that those “knowledge workers” can, you know, use their knowledge. The post has it backwards here. The problem in many organizations is that the knowledge workers have to micromanage the systems and organization around them in order to get their job done – to meet the goals and objectives they are quite capable of prioritizing and achieving. BPM’s job is to relieve them of work that can be automated, and to more efficiently present them with information they would otherwise have to chase down themselves. Think statuses of ongoing jobs and customer inquiries. Think monitoring bond payments to customers based on bond type. Think tracking important developments in engineering change requests.
It isn’t about micromanaging the knowledge worker, it is about relieving them from the micromanagement they’re forced to do in today’s organizations, just to get their job done. ACM doesn’t offer that – it offers to keep the knowledge worker right in the middle of every micromanaged decision – doesn’t that sound like nirvana.
Further down in the post (emphasis added):
My real goal today is to simply reflect on how the conventional wisdom to avoid micro management is diametrically opposed to the conventional wisdom of traditional human-oriented and server-oriented BPM. Everyone “knows” that you should not micromanage. At the same time, everyone “knows” that a BPM process should be as detailed as possible.
No, not everyone knows that, because it isn’t true. It is in no standards body documentation or body of knowledge work that I know of, nor is it in any of the certifications (OMG OCEB to name one). No sources cited – because, everyone knows, so no citation needed, right? (emphasis is his):
How can it be that there are no well defined guidelines to avoid too much detail in a Human BPM process? When do you stop adding detail, and when do you remove detail from a BPM aplication? I know of no such guidelines, and I challenge readers to post comments if you know of any.
Ah, now we need a citation, do we?
Well, here you have yourself a knowledge work problem, which requires subjective judgment. Defining the right model for a process is a craft. It takes experiencing knowing how much detail is too much, and where the details should go. I’ve seen guidelines documented by vendors. One vendor (in their product doc and methodology doc) used to recommend that process authors consider redesigning or using subprocesses if all the elements of the BPM diagram didn’t fit on the visible screen in the authoring environment. I wrote a similar recommendation in our methodology documentation at Lombardi – not a hard-and-fast rule, but a guideline to tell you when you should at least take a step back and reconsider your design.
Work with a Real BPMS
Of course, if you haven’t worked with BPM software that affords these kinds of refactoring and abstractions – with ease – then you probably can’t relate to the idea of making these design decisions “as you go” and “as you find your diagram getting too big or too complex”.
To the question of how much detail to include in a BPM Diagram – IBM and BP3 both have guidelines around this, and IBM’s guidelines are actually publicly available in their product documentation, and additional advice is available in their wiki and forums.
These are two things that IBM BPM customers and partners and IBMers take for granted- both the publicly available nature of their doc, and the ability to refactor the design easily -but I can see that it is a problem for some other BPM vendors out there.
Keith wraps with:
The amount of detail will naturally vary from person to person (depending upon their skill and experience). This makes it a big challenge to make everyone happy, but remember, since knowledge workers construct their own work environments, they can do as much as they want, or as little as they want, for their own tastes.
This is fantasy-land if your process involves connecting to other systems for information, or any potentially automate-able workflows that are not yet automated. The user is not going to wire those up or write the code. You almost couldn’t do meaningful ACM without there being a proper BPMS / BPM system to wire up all the things that actually facilitate the user getting free of the busywork.
A process is, after all, only as simple as it is.