I ran across an interesting article by Michael zur Muehlen and Jan Recker on BPM.com entitled, “Asking the Wrong Questions: Process Discovery on a Rainy Day.”

The interesting part of their article was their citation of a survey by Wolf and Harmon that organizations reported that more than a third of the time spent in their BPM projects went towards “process discovery.” There are two amazing things about this statement:

  1. Every BPM Software Company or BPM Consulting company knows this in their bones
  2. Not a single customer knows this (before they start a BPM project)

This is the central tenant on why BPM consulting and especially BPM project sales can be so tough. Anytime you have a gap between reality and expectations, you have disappointment. And points #1 and #2 above point to a classic “expectations gap,” as I like to call it.

Somehow the BPM implementation consulting team has to convince a company that it needs to first pay to “discover its processes” And this process is incredibly important (especially the payment part). I think a corollary to the Wolf and Harmon citation is that BPM projects that don’t spend AT LEAST 30% of the time on “process discovery” are bound to fail.

But should we be surprised?

No, not really. The same corollary holds for any type of software development. I’ve seen the statistic dozens of times regarding the percentage of all software design and development projects that fail. The number always changes but it is always somewhere near 50%. In fact, I think the odds a climber has of summiting Mt. Everest are greater than the odds of any given company having a successful software development and implementation experience on a given project.

The reason for failure in both cases is usually due to a lack of correct design and discovery and needs assessment. In other words, software almost never fails because of a software bug that just can’t be fixed. The same is true for BPM. Most good BPM Software out there on the market today (like ProcessMaker !) performs pretty well. The problem is in correctly identifying the processes to automate and integrate.

However, even more of a problem is that many companies (especially in the SME sector) will try and cut corners on the design and discovery phase. Everybody likes a web interface and a line or two of code and that is what most companies want to pay for. The result is that the initial 30% gets cut to about 15% and in the end the BPM software fails, or so says the disappointed client.

So the real challenge is how to get the customer to pay adequately for this initial phase. After all, your time is money if you’re a consultant or a software company. And you need to figure out a way to get this phase done correctly and to be paid for (otherwise you can never scale your business).

So, how is that done? That will be the topic of the next blog post, of course.