Question: Why do so Many BPM Projects Fail?
- September 18, 2010
- 4 Comments
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.