Someone had to do it, and I’m glad it was Theo Priestley, and not I!

Theo’s written up a summary of the Forrester-initiated BPM Jam on Twitter (thanks Connie!), and did a pretty good job of it.

Key points from his summary, where the idea that education needs to standardize (a la ABPMP), but also needs a more mature, comprehensive approach (a la Lombardi University). I missed this part of the discussion so I’m not sure how people felt about the OMG OCEB examination – of course, since that is a cert only, not a full educational curriculum, that may be why it was overlooked.

Another key point was the idea that a business architect requires 20 yrs of experience with Six Sigma, Lean, TQM under the belt.  As Theo put it:

I disagree somewhat on that point, whilst those methods are ‘nice to haves’ they shouldn’t be prerequisites of a Biz Arch and certainly not as steeped in the skills that they can’t accept outside influences. I’ve seen this among a lot of Master Black Belts and I don’t think they have what it takes to be a Biz Arch on this alone. Needs to be cross-skilled and understand architecture on a wider scale outside of process alone.

I think the key point Theo makes is that if you have adopted the religion of Six Sigma, or Lean or <fill-in-your-favorite-improvement-methodology>, you may be too inflexible to solve BPM problems in the most effective way.  A simple example I’ve seen of this is the Lean and Six Sigma ideal of ignoring technology while improving the process.  As with most doctrines, there is a kernel of a good idea there, but too often it is taken too far – to the point where many six sigma and Lean practitioners seem to be saying that technology can’t inform process improvement approaches – which any software engineer can disprove.  The real point of course is to not let technology slow down the process improvement, which is a very different thing altogether, and something I very much agree with.

“I know how eggs are sucked.” – Theo Priestley, in reference to a vendor giving a 90-minute overview of BPM to someone who has been an expert in the space for years.

I personally prefer the “Teach me to suck eggs” formulation, but this one works quite well also. Theo’s blog is definitely refreshing in its candor!

The Process Maverick (aka Theo Priestley) wrote a pretty interesting blog titled “Calling time on the BPM Conferences“.  In it, he points out:

In the last 6 months there’s a growing trend towards offering massive discounting or 2-for-1 deals (is this a professional meeting or a team huddle at Wal-mart ?!!) to try and attract the numbers. And it’s not working.

Lombardi pulled its famous Driven events from being physically located to purely Online now following a call from its members stating they could no longer warrant traveling and the expenses that incurred. Rumblings from the recent Spring Gartner BPM conference suggested that there was nothing new to warrant actually going. And more worryingly, a recent european conference had only 20 attendees….including the speakers ! It would seem the majority attending came from the Middle East and they understood a little about BPM and process initiatives but did they need to come all that way to learn ?

In fact, I’ve been hearing these rumblings about conferences in general, not just BPM conferences.  And there is reasonable evidence to show that BPM conferences are generally doing better than non-BPM-themed conferences (if you believe Gartner’s attendance numbers, their spring events were quite well attended).

Still, Theo’s criticisms are well-noted.  I think there is some consensus among those who regularly attend such conferences that there is not enough net-new content for a Gartner BPM Conference every 6 months, for example.  The beauty of a “Lombardi Driven” conference in past years was that it had a pull on different audiences for different reasons, and could satisfy their interests:

• Technical practitioners looking for practical help, tools, shared experiences
• Technologists looking at the road ahead, from a technical perspective, and for best practices from a technology perspective
• Business Process specialists at firms using Lombardi’s software, who wanted to get a little better understanding of the company and the products they would be employing
• Process owners looking for ideas for improvement, and inspiration and motivation to go get the budget they need to invest in their processes
• Executives looking for partners to help them expand from project to program.
• Implementation and ISV Partners looking for business opportunities
• Customers looking for help

I think what made Driven interesting was its focus on the practical. In a multi-vendor conference, not all the conversations can cross-pollinate as easily. Speakers at the more general conferences will tend to be more business centric, but perhaps at the expense of really drawing the right audience.  The format tends to be more presentation oriented than discussion (in fact, Driven was heading down that presentation/podium-focus as well, and the video-only version of Driven was completely devoid of the normal discussion that makes these events so worthy of attending).

But the real criticism of Theo’s that sticks:

“Isn’t it time the conference organisers woke up and realised that CONTENT is king and not the turnstiles?”

Yes, it is.  I propose a more barcamp-oriented solution (dare I say, crowdsourced).  Topics should be proposed by the community of attendees and presenters and voted on with feet (and web browsers).  The emphasis should be less about turning a profit from the conference, and more about breaking even, and creating value for everyone who attends, sponsors, speaks, or reads the notes later.  We have a tradition of this kind of conference in Austin, with Mr. Hurley being the driving force behind it.  I think there are some lessons to learn from this approach, that could result in a really effective BPM conference.

All too often I see conclusions based on observable data, where the conclusion does not necessarily follow the data presented.  This doesn’t mean that the conclusion is wrong on the face of it, but that it can’t be made based on the facts presented thus far.  Sometimes the conclusion is presented as causal when it is only correlated, sometimes it is extrapolating from a really small sample to describe the whole population (over generalizing).

I recently read Theo Priestley’s post on why Six Sigma doesn’t work in the real world.  In it, he relates a LinkedIn posting from someone attempting to do six sigma analysis on a call center process.  From reading the LinkedIn posting, it is clear that the person posting is not experienced in Six Sigma or other  related process improvement technologies that would be helpful to the cause.  This person is trying to figure out how to get a bell curve from a formula related to rate of defects in the call center process, where a defect is defined as a call response being over 60 seconds.  Theo extrapolates from this that it is an example of why Six Sigma doesn’t work in the real world, and why black belts are not needed (all that is really needed, he says, is a pragmatic approach).  And he quotes a response he advocates:

“…at the end of the day if you produce a bell curve telling me the USL and LSL for my call centre, along with the number of defects per million and a sigma value of 1.727, is this really a useful measure? More to the point, what can I – as a business person – do with it?”

Well, look. The response (quoted) asks the right question – is this a really useful measure, and what can I, as a business person, do with it?  In other words, are you wasting our time trying to figure this out in the first place?

But here’s the rub.  A good Six Sigma practitioner would not need to post to linkedIn (hardly the font of six sigma knowledge in the first place) to ask how to plot a bell curve to show USL and LSL.  So the poster hardly represents the “failure of Six Sigma in the real world”.  And a good six sigma practitioner could tell the respondent quite nicely:

If we can plot the response times of your call center, we can understand whether the process is “in control” or not – by which we mean, is it predictable and does it vary in a “normal” way from the median behavior.  If it *is* in control, then we can endeavor to improve the process by decreasing overall response time if too great a percentage of responses are exceeding your 60s window.  However, if your process is *not* under control, then this means that there are one or more special cause conditions causing the process to be more volatile. Therefore your first effort has to be on stabilization before you effectively focus on ratcheting down the long-term variation (i.e. drop the average of the process down as a whole).

Not that Six Sigma is the only tool available.  Lean has several tools that are well suited for call-center style efficiencies, and so does 5s (the Japanese concepts of organizing the workplace to keep things consistent and orderly in order to keep the process consistent as well) and keep in mind just like BPM, Six Sigma is continuously evolving with new tools and techniques and while the statistics is certainly an important part it’s not the alpha-omega that many who haven’t learned Six Sigma believe it to be; certainly not the Six Sigma of the 1980’s.

My problem with the post:  using one example of someone struggling with the concept of Six Sigma, to challenge the whole notion of using Six Sigma – a bit like challenging the concept of a 100-meter dash after watching me run it, instead of Carl Lewis – at least look at how experts apply the techniques!  Six Sigma is not a religion (or at least it doesn’t have to be!)- it is simply a set of tools that can be used to pragmatically improve your process by focusing on unemotional data rather than exposition based on anecdotes.  Not all the tools are even statistical, which was a surprise to me when I first studied material at the green belt level -but even those tools are very practical process improvement tools.  The biggest problem with Six Sigma in the past has been the C in the DMAIC moniker (Define, Measure, Analyze, Improve, Control).  BPM really helps address C by putting the controls in software (call center software can help with this as well), and it helps with the M by helping measure the process even when no Six Sigma blackbelts are paying attention.  This makes it a lot easier for them to drop in, interpret the data, and devise new improvements based on the data, rather than spending so much time collecting hand measurements.

Here’s a great post by Jason Cohen (of Smart Bear software) that illustrates that humans are terrible at making gut decisions that can be disproved with statistics, and how to help yourself avoid sample size errors at least when dealing with A/B tests (as in, which is better, A or B?).  Better yet, it has a cute video of Hammy the Hamster to assist.  It cuts to the point about how much data you need to get a reasonable sample size to draw conclusions, and I think it makes clear why data sets of less than 10 are just generally problematic.  Um, also, there are formulas involved, so if you don’t put much faith in mathematics, Mr. Cohen’s article may not be much comfort to you, but I promise the math required to evaluate your sample size will be easy to do!

In my view, the real problem with applying Six Sigma is usually people.  Turns out it takes skill and  judgment to apply Six Sigma tools in a way that helps the business answer questions the business cares about.  This isn’t that much different than the kind of challenge one confronts getting a business to adopt BPM, or a software package.  Let’s not condemn a whole professional practice with proven successes just because we have one example of someone who doesn’t understand how to apply it (or even 10 examples of such people).