In the early days of BPM – four or five years ago – everyone thought BPEL was the BPM standard, at least for runtime execution. Not long after, the importance of business-friendly process modeling came to the fore, and BPMN emerged as the standard for that. The mismatch between graph-oriented BPMN models, where you can route the flow just about anywhere, and block-oriented BPEL, where you can’t, didn’t seem to worry BPM vendors. After all, a model was just a model, a business requirements document in diagrammatic form.

The Challenge

I have come across businesses where some problems are chronic. In other words, these problems have existed for a long time but nobody attempts to fix them because they are thought to be “unfixable.” I have also come across businesses where problems are approached with a quick-fix mentality.

 In the past year I’ve heard increased chatter about the need for improved facilitation skills in the BPM arena including at the November New York BrainStorm BPM Conference where facilitation skills were highlighted as a necessary competency of Business Analysts¹. So what are these facilitation skills everyone is talking about?

What is Facilitation?

Simply put, facilitation is a structured way of helping teams think, discuss, and make decisions in order to achieve their desired goals. And, like any other discipline, it requires a specialized skill set.  The larger or more complex the situation, the more honed the skills of the facilitator need to be.

Erik Weihenmayer is an acrobatic skydiver, long distance biker, marathon runner, skier, mountaineer, ice climber, and rock climber. Erik graduated from Weston High School in Connecticut in 1987. As the school’s wrestling captain, he represented the state in National Freestyle Wrestling Championships. In 1991, he graduated from Boston College, and in the same year, he trekked in the Pamir Mountains of Tajikistan.

Two problems frequently encountered in planning for new product development are what I call the “depth problem” and the “breadth problem”. In my article “First Things First”, I talked about the depth problem – basically failing to spend time and resources establishing what to make or implement (the right concept) before committing to planning how to make it.