5 Areas BPM Projects Fail

Rainer Ribback
Next Post
Previous Post

5Areas.1171.v.2014.10I’ve spent over half of my career in BPM, and encountered quite a few projects in that tenure.  While some might call me ‘knowledgeable’, I genuinely enjoy BPM because its diversity enables lifelong learning and consistently presents new challenges.  Problem solving patterns may be similar, but each situation is unique, and as result, programs get challenged today, just as they did over a decade ago.  From my experience, there are a few key fundamentals that we at BP3 feel are in the critical path, and we wanted to share 5 representative areas around which we advocate for our clients below.

1. All Functions – No Metrics

A best practice that we follow in requirements and business case capture is to start with the metrics.  It’s the business equivalent of test-driven development.

The eco-systems’ lack of focus in this area isn’t just a BPM project problem. These patterns manifest themselves all over technology implementations.  I so often hear “lets get the metrics in version two”, but we feel that this positioning frequently inhibits Version 2 from ever happening.   The implementation needs a reference back to the business case. In general, performance and reporting metrics should be prioritized and incorporated into Version 1.   Instrumenting the proof points into your process is just too valuable to defer to some future phase.

2. Include the Business, and Mean it

Have you ever been to a party and asked to watch the kids? Suddenly, you aren’t living large like everyone else, you are the babysitter. Too many times, we have seen well intentioned IT groups invite business to the BPM program only to ignore everything they want or need. BPM is one of the best tools to actually break down the business and IT barrier (it is a core value proposition). BPM is technology equally for the business, as it is for IT.  Get business buy in, get their help, get them to demos of advancing work product, get them excited. Not only will active participation by key stakeholders drive adoption, but it will build stronger and broader institutional knowledge around your BPM program!

3.  Scope 

Much like when Jaws is approaching the local beach, you can feel scope creep coming, you can see the fin in the water, you hear the music, and you find yourself swimming in place.  Controlling scope is key to success. We’ve all been there.

Like most technology implementations, scope creep can kill project success faster than Jaws kil…. well, we’ve all seen the movie.  The bottom line is that BPM, at its core, is still an Engineering project, and the implications of scope need to be respected.  Late arriving requirements will almost certainly drive rework, and mastering the scope and timing is critical.  It is critical to complete certain foundational work at the start of the project, in order to mitigate risk, and get ahead of the ongoing scope reality.

4. Missed Adoption Planning

Thinking about adoption before a project starts is key to success. We often see business users print off pictures of their current system and say “build this”. This approach repeatably creates sub-optimal results. We typically want to build a better system, and not mirror the current system. Clearly capturing the voice of the customer is key to adoption. We advocate Lean Sigma approaches with our clients, in which the Voice of the Customer is the absolute truth.  If you’re not delighting your customers with the results (from voice of the customer activities), adoption is going to be out the window.

5. The Ambiguous Roadmap 

Building a roadmap, even if basic, is an important activity.  It is frequently the case that companies don’t take the time to sit down and think about how they want to execute in the medium term.  Building a good roadmap prior to starting project one is a great way to setup a ‘plan of reference’ that can be revisited throughout the initiative.  

We recognize that plans frequently change, but looking beyond the first release allows the development team to be thoughtful in how they implement their work (as well as management visibility).  Although the roadmap might change after Version 1, knowing where you are going is a great way to start. 

Leadership culture is a key theme here, as a plan should not be rigid.  Set a plan of reference, always revisit, and make adjustments as business and circumstances change.

Having a good business architecture is one of the key pre-requisites to assembling a good roadmap.

The above items are a snapshot of some of our opinions and practices for these specific anecdotes.  Above all else, we place emphasis on the Fundamentals of BPM, which we feel are critical in order to gain success repeatability.

  • An additional point, mentioned on twitter – lack of competencies. It takes time to build up the skills and organizational knowledge (and muscle memory) for BPM. And of course this isn’t just technical competency.

  • Pingback: Reasons why BPM would fail - BPM Failures()

  • #4 – The “build this” approach might not result in achieving the process improvements that BPM has to offer. If the existing process is defective (not optimized, has bottlenecks, data issues etc.) then BPM implementation will not do much to improve it. BPM implementation will simply make the process faster and possibly result in more defects (equation below will probably help).

    Existing Process / AS-IS (Per Day):
    10 Instances x 10% Defects = 1 Defect / Day

    BPM Implementation / TO-BE (Per Day):
    100 Instances x 10% Defects = 10 Defects / Day

    • exactly the point of #4 – don’t just rebuild the old application (and process) all over again. it creates all kinds of problems:
      1. no improvement
      2. no compelling feature to drive adoption
      3. no ROI
      4. may actually be harder to implement “the old way” than to leverage the new tools the way they’re meant to be used.

      • Totally agree!

        And I was supposed to write “Spot On” before my comment, not sure how I missed that :), just added it.