Before you get too esoteric in your BPM efforts, make sure you tackle the basic, common problems that all BPM projects need to tackle:

• sponsorship
• functional thinking
• business change management (in addition to technical change management)
• internal communications
• consensus tooling and methodology
• expanding beyond the COE
• “how big?”
• building BPM skills

Read the article for the full scoop. These are classic BPM problems and we’ve advised many of our customers on these very issues, so I think we can attest to the relevance of the list.

Connie objects to the characterization by some of “BPM failures”, and has excellent advice for those who either see BPM initiatives stalling, or want to prevent them from getting stuck:

• Cut down the up-front time spent on process modeling.  There’s no reason you can’t continue to invest in modeling after your BPM initiatives are in progress.
• Knowing how to scope your effort. Getting projects that are too big to tackle, or too small to matter, can stall efforts.  Right-sizing process efforts is, unfortunately, still more art than science.
• Let business drive. Stated differently – make business drive.  My take: exactly, but don’t let them drive off the cliff.  Get them to lead, but don’t be an order-taker.  IT’s job isn’t just to implement, it is also to inform and consult.
• Develop a strong process-improvement methodology. Don’t ignore the methodology aspects as well as the technical aspects of BPM.

I’m reminded of The Graduate:

I want to say one word to you. Just one word… Plastics.

BPM is apparently going mainstream.  And now we’re seeing analysts (Connie Moore) and the industry note that there’s a career in BPM:

All of this background points out one major trend: A new career field is emerging for business process professionals, fueled by the growth of business transformation, business improvement, and business optimization projects.

What do the individuals in this new field need most? Process architecture skills, process analysis skills, process modeling skills, change management skills, Lean and Six Sigma skills — the list goes on. More than anything, the skills gap or skills shortage keeps BPM projects from scaling throughout the organization.

This comes as no surprise to me – as it seems, looking back, that most of my career has been focused on process technology of one sort or another (initially, supporting sales processes for complex products, and later, actually working for a BPM vendor… and now, working with our own practice realizing business processes in production software).

Those of us at BP3 have already made a career out of BPM as business process professionals.  It looks as though most of us on our team fit most closely to the “Prodigy” cohort, as defined by Connie.  An appropriate place to start for a boutique consulting firm – though we have our Gurus and Change Agents.

Connie Moore has specific advice for picking up the necessary skills.  She advocates “two in a box” for training new process professionals.  This is something I’ve advocated for a long time.  BPM is more craft than anything else – you learn from others, and give it your own spin based on what you bring to the table.

Connie also advocates employees attending training, and leveraging external resources.  Couldn’t agree more (hello, bpmCamp!)

Answer:  They don’t.

But this question was recently posed on ebizQ.  I frequently respond to ebizQ questions regarding BPM, but when I read this one, I read the first couple of responses and decided not to comment.  BPM “projects” that employ BPM software fail for the same reasons all IT projects can fail, nothing unique to talk about.  But my real issue was the phrasing of the question: “why do so many BPM projects fail?”.  Ask the same question but without the prejudgment:

“Why do BPM projects fail?”

And then the discussion is a bit more interesting. But saying “so many” we have to ask “as compared to what?”

Connie Moore wrote a long response that reflects my point of view on this subject (an excerpt):

Before delving into why BPM projects fail, we should first ask “who says they fail?” I think the “failed BPM project” canard is an artifact of the old business process reengineering (BPR) days when big bang reengineering projects really did fail by collapsing under their own weight. But I’ve worked in BPM–and workflow before that–for many years now, and to be honest, I haven’t seen that many BPM projects utterly fail. In fact, I can probably count the failures on one hand. Instead, BPM clearly involves a journey, and sometimes BPM projects and even BPM programs stall out because the organization hasn’t matured its understanding of BPM and/or in its in-house capabilities to deliver business process change across the organization. Companies sometimes take a long time—too long—to move through the maturity phases so they get from implementing individual projects that provide good but limited productivity/efficiency gains to instead tackling true transformational initiatives that go to the heart of business performance.

This mirrors my experience.  The only BPM projects that I’ve seen fail failed in exactly the way Connie refers to – collapsing under their own weight because they were run as classing BPR projects.

Some of the comments seem to be caught up in whether “BPM” has succeeded or failed, not whether a “project” (the subject of the original question) succeeded or failed, as does this comment from Thomas Olbrich:

First off, I think that BPM has not delivered. This automatically begs the question of ‘delivered what?’. Well, what are we talking about here? It’s BPM, Business Process Management, the management of business processes.

Fair point that many people have or had bigger aspirations for BPM than what it has, to this point, delivered.  But that kind of judgment of failure is very much in the eyes of the beholder.  If we judge by other yardsticks, BPM could be judged a success. But let me just say, that success is no excuse for getting complacent. We should be striving for more with BPM – not less.

Thomas goes further:

So, after this rant-de-force, who is prepared to tell me that
• Our processes are managed better today with the availability of BPM?
• Our enterprises have really become more agile, more flexible?
• Our processes have become more application independent and quicker and easier to adopt to customer requirements?
• Standards like BPEL and BPMN have facilitated the transfer of business requirements into IT?
• That the quality of processes and process management has improved?

Yes, there are ways to adress these issues and to achieve these goal, but as long as we insist on this make-believe approach of ‘easy BPM at the push of a button and the purchase of a BPM system’, I fear we’ll never get there. Managing processes is a complex business and anyone reducing it to projects needs to be very lucky indeed. BPM is an intellectual challenge and not a technical one. Have we got the right people with the right attitude to make it work?

If anybody can convince me that things are indeed better than they seem to me, I’ll bow my head in shame and apologize (from a safe distance).

Well, I don’t anticipate that I would convince Thomas, but I do believe that processes managed by BPM are, by and large, managed better than they were before.  That enterprises who embrace BPM are more agile and flexible than those that do not.  That BPM-implemented processes are indeed more application independent and quicker and easier to adapt/adopt customer requirements.

However, I agree with Thomas that we have got to drop the idea of push-button BPM – or that managing processes is easy if only we have the right silver bullet.  It isn’t easy.

Connie’s last thought sums it up quite well:

But let’s say that an organization’s BPM initiative suffers from certain problems, such as not delivering as much business value as expected, or taking too long to complete a project, or providing limited value because it was just an isolated pocket of the organization. These are some of the common problems I’ve heard, but I believe it’s not so much failure as it is getting stuck in the business process improvement/transformation maturity life-cycle and needing a kick start to get going again. Also, failure is in the eyes of the beholder so one project team’s success may look like failure to a very senior exec who had much greater expectations than were delivered.

Very very true.  If BPM is a journey, failure is giving up and going back home.

Good article from Connie Moore of Forrester yesterday, on assessing the BPM market the day after the Savvion news broke.

As she points out, these deals are important because of:

• Convergence of BPM types
• Clear signs of expanded interest in BPM by big players
• Closer integration of several business technologies (BPMS, BAI, etc.)
• Better BPMS from IBM
• More acquisitions and consolidation to come

Connie goes on to give her impressions of Pega, Appian, and other pure plays and innovators.

Like Connie, I think there’s still a lot of room for innovation in the market as the creative-destructive capitalistic processes continue.  She also took time to point out that many of the acquirers do not understand that there is more to BPM than software- there is a methodology and discipline of continuous improvement that most software vendors simply don’t have, and don’t appreciate (at least, as it pertains to their customer engagements – they may very well practice continuous improvement inside their own organization). I think this acquisition activity is going to put further demands on service companies to bridge the gap.

Connie Moore’s (of Forrester) recent posting on collaboration and BPM got my attention primarily for the following quote:

But I’ve been a voice crying in the wilderness. I’m not kidding.  Whenever I would talk about collaboration with BPM vendors, they would somehow think I was talking about straight through processes between companies. That’s collaboration, right???  And whenever I would talk about BPM with content and collaboration vendors, they would look at me blankly and mumble something about using simple workflow for approving documents.  It felt like two disconnected worlds that desperately needed to find each other.

I can very well imagine this conversation with these vendor communities.  Connie sees reason for optimism, and I agree – but we still have a long way to go on this front.  Keep fighting the good fight!