Blog

The Myth of Micromanaging (with BPM) by

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.

Everyone Knows

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.

  • Emiel Kelly

    Scott,

    Nice post, but… At first I think BPM is not about diagramming but about using processes.

    And I agree with the fact that sometimes you need diagrams, but that detail is the largest danger. For some companies the easiest way to save money with diagrams is to stop with making them ;-)

    But the only thing that makes sense for a process is executing it. Using it.

    Using the processes to deliver what you promise. In the end a process is never a goal, but a means to deliver a result (product, service or solve a problem).

    And every company already has those processes. I think BPM is about ‘awarenize’ and ‘vitalize’ them. And that can be done in many ways. And that is where the ‘fight’ between ‘detailed workflow’ and ‘loose acm’ seemes to comes from. Thinking out of on truth.

    Every process is unique and needs it’s own way of managing. And sticking to (ok let’s call it that way) micro management when more goal-oriented is suitable, might be a waste. And the other way also. Building a car and let everyone do what he thinks is best, might work for that one special supercar (build in a shed in Italy), not for a mass produced sedan.

    So maybe it’s time the BPM industry (and I don’t mean vendors by that) stops the workflow vs acm fight and comes with good examples what level of process management worked well for what type of processes.

    Processes do not only happen in administrative environments. Growing potatoes is also a process. So treat those processes with respect and manage them in the way they will perform the best.

    Processes have a heart too…sniff

    • http://www.bp-3.com/blogs sfrancis

      “Nice post, but… At first I think BPM is not about diagramming but about using processes.”

      I think this quote misses the point – i’m just responding to the original author’s targeting of the BPM diagram, not saying that the diagram is the goal. In other words, no “but” required – I agree BPM is about using processes.

      “But the only thing that makes sense for a process is executing it. Using it.”

      Are you sure about that? drawing it on the whiteboard to explain it doesn’t have value? If the diagram doesn’t have value, only the execution has value, then why do we not just write it all in code? Or in assembly language even? We use diagrams because they can increase understanding of key aspects of the solution without as much detail as the actual code that runs. This is the purpose of most abstractions and models – enhancing understanding of something with either a simplified or targeted perspective on a set of data or context.

      There isn’t a fight between detailed workflow and “loose acm” – that’s the fight ACM folks want you to believe is happening. ACM folks imagine that BPM requires incredibly detailed micromanagement to be done well – it does not. The only fight is between people doing BPM well, and people who want to define BPM as something that by definition is bad.

      • Emiel Kelly

        ad 1 we agree ;-)

        ad2

        Sure diagrams have value (especially on a whiteboard ;-), but in the end only the executing of the process makes customers happy.

        That’s what I meant. Always think with (improving)executing in mind. Don”t think for the sake of thinking.

        ad3

        I think you are right.

  • sagar

    Nice Post Scott,

    BPM is definitely not about micromanagement. its about automating activities that would ease life. And regarding diagramming. I think diagramming is as important as executing.

    You have to be able to visualize to be able to execute effectively :)

    Regards,
    Sagar
    http://www.thinkflows.com

    • http://www.bp-3.com/blogs sfrancis

      both good points, Sagar, thanks!