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

How do you avoid the BPM backslide?

Vote 0 Votes
According to this blog at IT Business Edge, Gartner's Jim Sinur refers to it as elastic behavior, the resistance to change that sometimes causes users to revert to their traditional behavior instead of sticking with improved processes. So how do you avoid the BPM backslide?


8 Replies

| Add a Reply
  • Backslide of any business improvement comes less from helping business users on the ground 'visualize' what the improvements will be (many users are excited to try something new, even if they won't admit it publicly), it comes from supporting them effectively when reality bites and the new processes are in place and things don't quite work as expected. Every project sees unexpected issues, and hand-holding users through the early stages is one way of ensuring small issues don't "backslide" into user revolt.

    The other essential item comes from the top. There must be visible and vocal support from a trusted executive. Few users or managers will talk negatively about a new process or solution if there is strong support at a senior level from a figure-head they respect. Without "backchat", there is less likely to be backslide.

    Finally, the iterative point of view discussed in the article is essential, although not always for the reasons expected. Of course, small manageable project chunks are more likely to be successful, but the reality is that users need to believe that their concerns with a new solution will be addressed in the future. This is in contrast to typical projects where everything useful is planned for "Phase 2", and as we all know, Phase 2 never happens.

    The reality is that software vendors can't really deliver this. Even consulting firms struggle to support when the project is delivered and the retainers get cut. The success of a new process has to come from inside, and this needs the process to be seen as a living, breathing thing, not something that we are going to allow to stagnate.

    Phil Ayres

  • I'll elaborate on part of the Deb Miller quote in the article referenced by the question. She wrote:

    A good way to make change stick is by creating an interface that delivers content within the context of the work that is done every day. When you get the user-centric emphasis right, the results can be outstanding.

    Right. That is the key. You have to make the end users more productive. If you implement a new business process and in order to provide greater visibility to upper management, but the daily work of the employees is less efficient, then they will avoid the new way. But there is no need to make that trade off. With a BPMS that can incorporate the appropriate context with the tasks presented to the user, there will be no need to force them to use the new approach, since they will want to use it.

    A good analogy might be smart phones. Once someone has a smart phone and can get at their calendar and email whenever they need it, they don't choose to stick with the old way of opening up their laptop anytime they want to check their calendar.

    I'd say an analogy for the wrong way would be some automated checkout machines at grocery stores. The grocery store becomes more efficient, but the user often pays the price when things don't go smoothly (as so often happens with those systems).

  • It starts from mindset in the project/program. Is it an IT project? Or is it a business program? If it is a business program, then not involving the business (users, owners in IT lingo) would be a glaring sin! But, the fact that they are referred to as users and business leads, tells us that in the minds of people it is still looked upon as an IT project.

    Business Process Participants, when treated as users of a system being delivered, will always get missed out.

    And when a change is thrown upon them - as against they being part of the whole improvement program with the inputs from the turf - they will resist. Force always meets resistance even if your interfaces manage to reduce some friction. Take them along - perform demos, do simulations, get interactive process workshops, and then go and do IT work as needed in parallel.

  • Thanks Michael! I agree that the "what's in it for me" aspect cannot be underestimated.


  • If you have properly captured processes, a BPM process should eliminate and/or prevent ‘backsliding’, and any instances of reverting to original processes should be very obvious to process managers and owners.

    Now that is the draconian answer….

    I agree with the other responses that if the process discovery adequately captures the intent of the business and the requirements of the day to day users, then the risk of falling back on old ways is greatly reduced.
    Leading BPM companies have been delivering access to process application in both portals and productivity applications for years, and outside of a relatively narrow band of low value processes, this has not really taken off.

    In many organizations the really critical processes are so unique they do not have a place to live. While portals form stack vendors can be the home for processes, this can add complexity and additional cost without a lot benefit.

    I am not sure if I totally agree with Phil’s comment about “Phase 2 never happens?. I am all for small deliverables, but one thing I have seen in our customers – and in contract to traditional application development or ERP implementations – is that Phase 2 almost always happens and starts towards the end of Phase 1. BPM solutions should make Phase 2…and Phase 3 easy.

    Maybe we are just mincing works around phases and iterations?

  • like greg, I look at the backsliding issue as dramatically worse in the world before BPMS... ie, six sigma or lean with no software or technical implementation to back up the improvements. eventually discipline, training, and cross training fade... but software can help prevent the backslide. (Of course, it can also act as friction against a further improvement, if not done properly).

  • Backslide is sometimes just the way that people looking the wrong way describe progress.

    I have seen many organizations where BPM is viewed as a sort of "reigns" to attempt to force people into patterns of behavior that serve their purpose. What will sometimes happen is that one group will get very proactive about changing a process, without necessarily getting input from all stake holders. C'mon, you all have seen this. Couched in the language of "process improvement" what they really mean is "get those people to do the job (I think) they should have been doing all along."

    I am not saying that all process improvement is this way, and I also don't mean to say that "those people" should not change the way they are working. However, the new process may not be optimal for all people. The new process may shift the burden of work from one group to another. Not everyone may agree that the new process is beneficial. This could be because the people who designed the process did not get agreement on the new process from all stakeholders.

    The term "backslide" is then a way to place the blame for the not changing on the people in the process. We don't know in the abstract whether this is good or not.

    Any case of backslide is clearly cause by a lack of agreement on the new process. It is a signal to re-examine the new process and see whether it really is an improvement. Then, communicate the benefits to all participants. Finally, address any burden shift and somehow reward people who have additional burdens under the new process. In other words, finish the job of culture change around the new process.



  • Lots of great insight and comments by all. Some of these points are worthy for further discussion/analysis/deep dive.

    I came back because I want to quote one of Keith's lines above just to drive home the point we are all discussing (Keith's line, btw has the disadvantage of being lost in a lot of other great points in his post!),

    "Any case of backslide is clearly cause by a lack of agreement on the new process."

    this line probably says it all.

Add a Reply

Recently Commented On

Monthly Archives