One-Hand Clap

  • July 9, 2012
  • Scott

Jaisundar’s post on Bouncing Thots regarding the biggest barrier to companies starting a BPM project was pretty spot-on:

But really, some of the best BPM projects have failed because of this particular problem. With BPM it is so very important that two hands come together to clap – both the external enablers (vendors, product specialists, SIs, consultants and all of that) and your internal enablers (process owners, users, IT teams,  Management, etc.) .

Just one hand cant pull off a clap.

There were several other good responses on the ebizQ forum, admittedly.  And only one person who just threw IT under the bus(!)

But Jaisundar has put his finger on a big issue. Many companies can not look themselves in the mirror and realize that the roots of current failures were planted inside the company, not outside.

As for the “outside” issues, there are many:

  • Wrong partner, or issues with partner chosen
  • Wrong technology, or issues with technology chosen
  • Budget issues
  • Economic conditions change
  • etc.

But most of these if we trace back to the root – who chose the partner? who chose the technology?  How were those decisions made?  How were they policed or validated later on?  You get the idea.


Related Posts
  • March 14, 2018
  • Scott

We're heading to IBM's Think! conference next week, and we want to share some of the sessions that jump out to...

  • March 14, 2018
  • Ariana

The Importance of DevOps from BP3 on Vimeo. What is DevOps, what does it mean to customers and how are pe...

  • March 11, 2018
  • Scott

One of the things our engineering team does really well is keep improving the rough edges of any product they ...

  • Gary Samuelson

    Interesting to read on about a project measured in terms of strict success-over-failure  (vice-verse). Seems to me, at least, as something measured along the side-lines. Like measuring the parade… being either too long or short. Making the difference in success – surely. As if each project had every right to succeed at the beginning. And, it was only a matter of accumulated troubles along the way. Sized and reevaluated just prior to discovering a “no end” solution?


    A bad BPM project fails the day it started – unfortunately requiring a few months of trial prior to looping back to its begging. And (from point of embarkation) seeing the back-side of failure.

    Half way is further from day-one. Maybe try something more “agile” and learn to regroup and change course along they way… .next time.

    • Very true that the most telling mistakes start before the “project” starts 🙂 
      But being able to pivot/adapt/change-course is a good way to rescue victory from the jaws of defeat.