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
  • July 20, 2017
  • Scott

Your BPM initiative has produced great ROI over the years, but your executive team is more focused on a hot ne...

  • July 18, 2017
  • Ariana

In this video Andrew Paier explains when you might want to allows users to complete digital process automation...

  • July 13, 2017
  • Scott

Today IBM made its announcement about partnering with Automation Anywhere to create waves in the RPA Space. (Y...

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