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
  • October 18, 2017
  • Scott

The Institute For Robotic Automation defines RPA as: Robotic Process Automation (RPA) refers to automation wh...

  • October 18, 2017
  • Ariana

Headless BPM from BP3 on Vimeo. In this video, Carmen Galicia walks through using external user interface...

  • October 10, 2017
  • Ariana

Planning Your Project Roadmap from BP3 on Vimeo. In this video, Andrew Paier talks through getting started ...

  • 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.