We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What is the number one reason a BPM project fails?

Vote 0 Votes
What is the number one reason a BPM project fails?

26 Replies

| Add a Reply
  • The answer is in the question.

    Because it is seen as a project, not as daily business.

  • Subject... matter... expertise. Period. End of discussion.

  • When IT take an interest! But that is changing - it has to!

  • Failure to manage change

  • "The client lacked the maturity to implement the solution..."

    If I look back at our failures, 4/5 times either myself or our head of projects knew a project would fail from the beginning. So the next question is - why couldn't we stop it from failing? The answer is very simple to identify but very difficult to put into practice.

    Maybe it sounds cheeky for me to lay the blame on the client, but in fact, I am not doing that. You see, there is a second part to the answer above (hence the ellipses), and it is the following:

    "...and the BPM project implementation team didn't tell the client."

    As I said at the outset of this post, the BPM team usually knows a failure from day one of a project. The problem is that there is usually too much momentum from the sales side to admit this, and not enough internal discipline to turn away the business.

    By lack of maturity I mean that the client is either too small, doesn't have their project well defined, there is too much internal politics going on at the client, there is a lack of leadership at the client, the client doesn't have a clear vision of how the project will deliver ROI, or the client's implementation team simply has other priorities coming from some other part of the client company's leadership team.

    These issues can't be fixed by the BPM implementers, so the only way to improve one's BPM success rate (from the vendor perspective) is to have greater discipline and turn away more business.

  • We actually published a white paper on just this subject that included a lot of supporting research. One study in particular found that the most common reasons for BPM failures are:
    -Underestimating the impact on business
    processes and organizational structure
    -Improperly trained users
    -Project derailment by internal politics
    -No implementation of adequate governance

    • Ha ha, doing BPM and then expecting it will not have impact on your business processes....that's a good way to start

      Let's take a medicine and hope I won't get better.

      And I see now I forgot to ask my standard question:

      Are we talking BPM or BPMS?

      • I don't think it's that they didn't expect any impact, just that they underestimated the amount of impact that BPM would have on not just their processes, but their organization as a whole.

        • Oh yes, I see that a lot too. If you are really ambitious to manage by processes; with that ambition comes sacrifices.

          Then you will see the separation between the real (wo)men who have the guts and the boys who say 'let's finish this BPM thing and please get back to normal work'

          That's why treating bpm as 'another project' is weird. Managing by process is day to day business and I hope it will shake up organizations! Especially the ones that have me as a customer ;-)

  • Not sure about NUMBER ONE, but a big factor I have seen is treating a BPM effort as too much of an IT project and not a business project, with required organizational and process change. In cases where that *was* clear, then a big factor is inability to actually implement the new processes - no power or influence to make the necessary changes to meet the goals.

  • Success, as they say, has a thousand fathers; failure is an orphan. Bring on the paternity tests, then, because there are a few candidates.

     > Politics. Specifically, as mentioned by a few others, above: failure to get the necessary support from management. This does not mean that BPM projects have to be sponsored from the top down. But it does mean that you need at least a modicum of financial and political backing to get things done.

     > Skills. You shouldn't need to be a programmer to roll out BPM, but you do need a certain comfort level with technology. Make sure somebody on your team has it.

     > Expectations. Keep them small at first. Overwrought expectations are sometimes a result of vendor hype, but just as often, they're a natural outcome of the internal sales process needed to get a project off the ground.

    Get the proper backing, ensure you have the right team members, and manage expectations all around, and you are going to have a much better shot at success.

    • user-pic

      I like this summary, Scott; it's succinct. These 3 points apply universally to the success of any project. It's not like BPM projects are magically different from any other cross-departmental initiative.

      However, I'd add to point number 2 (Skills) that not only the right technical skills are needed, but also the right communication skills.* As noted by Brian (tell the client the truth); Theo (need for common understanding); Samantha (proper training and need for a common goal).

      *And proper articulation, what with Theo's silent "IT" and unpronounceable "US."

      • Well said! Communication skills are absolutely critical as IT and business stakeholders begin working closer together. In order to apply BPM effectively, there must be a shared vision and strategic alignment between IT and the Business. It all starts with Communication.

  • Enjoy many good comments above, for BPM project, you may need begin with the end in mind, well define business problem need be solved, is it for process automation, innovation or optimization,as folks mentioned, don't make it as technology challenge only, it's all about business & customers. thanks.

  • Sam and Emiel +1

    Number One reason ?
    Lack of consistent communication and expectation which stems from an inadequate understanding of what BPM is.
    People will translate it in a myriad of ways and as such there will be no common understanding of the goal, method or implementation.

  • The B in BPM stands for BUSINESS. BPM does not have a silent I for IT

    Business driven, business change, business outcomes.

    Not IT system, IT project, IT implementation

  • >> The general notion of Workflow = BPM is also one of the reasons for a Project failure. BPM ecosystem offers much more than that. But we just force fit the product to ensure that we have leveraged BPM in most of the places in the enterprise.

    >> Moreover at times even the lack of focus/roadmap in organization plays a crucial role is crucifying the Project just because the person in power has got the product as one of their competitors have also implemented BPM using the same product

  • Process underpin business capabilities, business capabilities decides how well business executes strategy; BPM team may need visit business strategy to ensure the project has well defined goal and meet business perspectives. thanks.

  • Peter,
    I would stay away from the cultural and sponsorship aspects of it because that is not my domain of expertise. The reason why BPM projects fail in my experience is the brittle nature of solutions built to work around the capability of the underlying tool. Often, we have seen IT departments writing code because the tool cannot really support the nature of business. The moment the process gets complex in dependencies, most of your off shelf products throw up. You cant have this cross branch dependency, you cant loop back to this activity because its a grand parent, sometime you can never loop back. All of these limitations create unrealistic processes, very different from the ones that business desired. And when business suggests changes to the process - the already built brittle solutions are ready to crack - causing the other teams to say "NO", or it will take another 3 months. And by then the morale and executive sponsorship have run through the course :)

  • Asking for the number one reason that BPM projects fail is audacious. But important.

    Here's a short answer: BPM projects fail at a rate higher than tolerable (thus the question) because BPM projects, being fundamentally different than all other IT projects, are not yet sufficiently supported culturally, organizationally and economically.

    In fact, the first response to ebizQ's question, from Emiel Kelly, alludes to these issues with the statement that BPM is seen as "a project, not as daily business". Subsequent comments by other contributors elaborate in worthwhile ways. But it's worth making Kelly's "not as daily business" explanation more explicit.

    Specifically, from the original answer above, what does it mean that BPM projects are "fundamentally different", and why is this difference important? And what is "cultural, organizational and economic" support?

    BPM technology is fundamentally different than most or all other business technology in that it is directly and explicitly "about business", which is not the case with most other technologies. In the case of BPM there is the opportunity, even hope, that business executives will be directly involved in short cycle artifact construction of business process tools.

    BPM technology ushers in wonderful business opportunities, but these opportunities are the source of enormous organizational stress. The stress is because of the success of the technology; specifically the removal of "wait states" between request and deployment is a cultural and organizational shock. And as organizations are also economic entities, this new high-pressure scenario is also economically fraught.

    The removal of the development "wait state" means that an organization has the opportunity - and even an imperative - to accelerate organizational adaptation. (Given the pressures on today's business and governmental organizations, adaptation is even essential for survival.) And the burden on organizational executives unused to having to "think on their feet about process" will also be substantial.

    Developing business processes "top down", Soviet-style, is not the answer. Given the complexities of business and process, successful businesses will have to develop processes "organically". You could say that these organizations will require a "process discourse". "Discourse" is short-hand for questions of anthropology, sociology and theories of narrative and communication which have received so much attention in the last 20 years or so. So much BPM assumes that it is possible to define a process, that canonical processes exist, that we are all using the same vocabulary concerning the subjects of work. And truly, if we are to communicate using language, and to work in concert, some common understanding must exist. (See for example material on the "social construction of reality".) But computers and IT are very unforgiving, especially where fuzzy reality is concerned. One doesn't need to be a fan of post-structuralism to admit that business communications are often inadequate for the job, including the communications around many failed IT and BPM projects. And especially now with the no wait-state pressure for real time process adaptation, the development of a new process-positive business discourse or process culture will be essential for any successful organization.

    The vision presented here is likely several years out. But the trend is clear and already business executives are under the gun to understand and lead. The many comments provided by ebizQ correspondents show examples of "failures to communicate" and "failures to generate" [ideas]. It is worth putting these phenomena into the perspective of an overall trend. It's not enough to say "you should communicate better with IT" or vice versa. Because on a daily basis executives in both business and IT are overwhelmed with organizational change and terrible economics. Just trying to "communicate better" is a pale nostrum that enables executives to ignore their new responsibilities.

    Masters of process, masters of strategy, master of business models. In the world of process, which is fundamentally integral to the world of the business model, leadership and a process-supporting culture are the orders of the day.

    A longer version of this item is posted on your correspondent's blog here: http://www.decisionmodels.org/content/no-more-wait-states-bpm-opportunity-puts-pressure-business-executives

Add a Reply

Recently Commented On

Monthly Archives