Question: Why do so Many BPM Projects Fail?

Scott Francis
Next Post
Previous Post
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.
  • Pingback: BPM Quotes of the week « Adam Deane()

  • Scott, I hope that I’ve retained enough of an open mind to be convinced by other arguments :-) and I admit that I was in a rather foul mood when I wrote down my comments on project failure – or as you correctly point out – BPM failure, which is a slightly different issue but not unconnected.

    As long as BPM initiatives are treated as projects (a project has a limited and pre-defined lifespan, since when is that true for processes?) and reduced to BPMS, I still fail to see how BPM and projects are going to be any more successful in future.

    Thomas

    • Thankyou for your comment, Thomas. So, if we can talk separately about BPM project success/failure rate and “BPM” success/failure, then we can focus on more consistent metrics.

      Regarding BPM project – if the project meets the objectives set out at the outset, I’d argue it is a success. If those objectives include budget, timeline, ROI, and other measurements, that’s a good thing. Is your contention then that BPM projects fail more often than other projects at companies? or more often than IT projects generally? My experience has been the opposite – more likely to succeed, and the projects heading to failure are more obvious than traditional IT projects.

      For “BPM” success/failure I think there’s a lot more disagreement on what constitutes “success”. I think we can agree that if one starts on a BPM initiative, and only achieves a single successful project with a BPMS, that this is not a successful initiative or program. Kudos on the successful project, but until it becomes part of the culture and a repetitive experience, it isn’t really an initiative or program. What do you think it takes to constitute BPM success?

  • Pingback: Happy New Year » Process for the Enterprise()