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
BPM
user-pic

Why Do So Many BPM Projects Fail?

Vote 0 Votes
From a discussion on LinkedIn, Why Do a Majority of BPM Projects Fail? (which requires you to join the group), why do you think so many BPM projects fail?

27 Replies

| Add a Reply
  • From my experience, projects fail because:

    - Convergence - BPM is as much philosophy and methodology as it is product. So for a BPM project to succeed and really take off within an enterprise philosophy/methodology/product knowledge must all come together in full support.
    - Ignorance - Internal team members often think they know what they are doing without going through proper product or methodology training. They begin building when they should be gathering more details (to Victor's points 1&2). And they don't get the details required becuase they don't know the questions to ask becuase they are not steeped in product knowledge or methodology.
    - Churn - People come and go. When core project people - developer, project manager, key analyst, executive evangelist - leave companies must often start over with resource development.
    - Blinders - For BPM to really take off, a company has to use it in more than just one area. If a company uses BPM to build a claims system and no other application, then what happens is executives see BPM as only a claims product not a app dev platform. This issue goes back to the first point. BPM is a philosophy driving operational efficiencies and effectiveness. It can also be used to streamline almost any process. If the team only focuses on one process and doesn't get the concept that BPM can be applied elsewhere, then BPM will only have limited success and can easily be replaced by a COTS app in the future.

  • No 1: Lack of understanding of what BPM is !

    And the rest in no particular order:

    - the belief that BPM is actually another Lean/ Six Sigma initiative with a bow on top;

    - it's just a software solution;

    - it's not driven from both the top and bottom rungs of the organisation at the same time;

    - no appreciation of what the end goal is;

    - Big Bang approach rather than proving it works in smaller chunks;

    Could go on and on but this topic has been done to death and still no-one actually learns from it. Perhaps that's the biggest failure of the industry itself....

    • That's it, Theo, no-one learns from it. A minimal requirement for such a question to make sense, would be a classification of 'Business Processes' according to the field they are designed for. One might then find correlations between failure and kind of field - possibly even could refine the classification.

  • I only recently blogged on this topic, though was more at IT projects in general. However, the same applies:

    Lack of Understanding - what is the technology and what are we trying to solve...

    Internal Politics - who should be involved, who is doing what...

    Nepotism - Some people are involved in the project and simply shouldnt be, they are involved not on merrit rather other reasons....

    Incompetence - Usually at the business side of things. People simply dont know their own business who are key players in the project. In addition, I have worked with some vendors who provide consultants who simply are incompetent...

    Resistance to change - this can be at any level. Either the backing is not there at higher levels of management, or by middle management or by actual users. Any resistance will cause issues and potentially make a project a failure. Since BPM covers so many basis it is more likely to find resistance somewhere to change.

    My blog post can be found at :
    http://andrewonedegree.wordpress.com/2010/09/08/why-it-projects-fail/

    Please add your own comments to that post too...

  • Good thread! In my experience projects fail most often because of a failure to properly involve the stakeholders. And those projects that don't fail suffer "backslide" most often because of this same failure. I shared some thoughts about this recently http://bit.ly/dtD8mZ.

  • When you write a book you think about the audience. You don't just boot MSWord and start typing.

    So why do BPM projects turn into "Let's automate this process" or "Let's map this process" with no thought of the eventual recipient ie end user.

    So user adoption is often at the heart of the problem. Discussed at length (200 pages) in my book Common Approach, Uncommmon Results.

    A good implementation example is Carphone Warehouse. Here is a video of the end (real) users in the Richmond store, videoed with no warning or scripting. http://bit.ly/DdUkQ

    Carphone Warehouse using their B2C marketing savvy to really engage the end users, and in return got a staggering ROI. Here is the video of the project sponsor. a very happy chappie. http://bit.ly/93L1s2

  • My answer has little to do with BPM itself or any special significance in BPM as a philosophy. Rather,I will take the perspective of a BPM vendor to answer the question of why BPM Software implementations often fail. These reasons tend to be the same for any enterprise software project:

    1) Poorly scoped SOW - you wouldn't build a house without a blueprint so why do so many projects fail to invest the appropriate amount of time and energy into creating a quality Statement of Work?
    2) Strong Counterpart - Has the customer assigned a strong counterpart to the project? Is this "inside" project manager capable of building consensus, fending off political attacks, and maintaining momentum?
    3)Project Management - Poor project management has got to be the biggest cause of failure. On the other hand, top notch project management can make up for failings in any of the above named issues.
    4) Managing Expectations: The most important part of project management is all about managing customer expectations and tackling differences in expectations as soon as they creep into the project.

    -brian
    http://blog.processmaker.com

  • For the reasons many IT projects fail. The topic has been beaten to death now...

    What makes life of BPM project even more hazardous is following in addition:

    - fight over the fulcrum for BPM leverage between Biz, IT and EA

    - fight over scope and definition of BPM among vendors, analysts, community

    And to top it all, this trendy domain keeps picking new trends and gets more and more amorphous while customers need some shaping out there...

    For more specific reasons, just turn to any Software Engineering practices and top them with best practices over business strategy-operations alignment and you got it all.

  • Many BPM projects fail because no one steps up to claim ownership of planning and monitoring workflow automation, and without clearly defined efficiency goals many departments implementing BPM can't identify key business processes to actually manage.

  • I see some consistent themes amongst Forrester's Business Process Council members. I would categorize the things that are blowing BPM Programs off course into: 1) Education, 2) Senior Management/Exec Buy-In and 3) Change Management.

    1) Education: BPM is where EA was 10-15 years ago; there is no singular, agreed-upon definition of the discipline of BPM and there is a lack of consensus around roles and responsibilities for managing a BPM Program. Our members who have successful BPM Programs have been able to make their organizations aware of the fact that BPM does not equal a tool, that it has to fundamentally transform the business and its operations, and that it’s nothing to be afraid of!

    2) Senior Management /Executive Buy-In: A lack of visible, senior leadership engaged in the BPM Program and driving aligned performance incentives is a show-stopper. But this gap tends to be a symptom rather that the root cause, which I see as lack of executive education (see above bullet), leadership changes before the program is sustainable, and a lack of willingness to assign process ownership. Something most members have in common is that they were able to demonstrate early successes with proven ROI to help garner that exec buy-in.

    3) Change Management: Education and Change Management go hand in hand. But you can educate and even have executive buy-in, and still not achieve the level of change management required for successful business transformation through process excellence. Successful change management is the ability, discipline and tenacity to engage the business in a continuous fashion. Council members that do this well have an explicit framework, roadmap and milestones for change management that includes communication, training, aligned performance incentives and most importantly, a connection to customer focus. Finally, not having an approach to change management before bringing in a tool? Kiss of death.

    • ... and also: Ultimately, not having a broad understanding of automation and computing-technology transfer, in terms of a solid model (based on first principles), before tackling change management? Sentence of death.
      Summing up, where members of whatever 'Coucil' agree, is no valid substitute for besaid model.

      Good news: model available
      Bad news: model largely ignored
      Straight info: www.mastering-it.com: Basics (Technology Transfer); ... / What to Know (Automation)

  • Before delving into why BPM projects fail, we should first ask “who says they fail?? I think the “failed BPM project? canard is an artifact of the old business process reengineering (BPR) days when big bang reengineering projects really did fail by collapsing under their own weight. But I’ve worked in BPM--and workflow before that--for many years now, and to be honest, I haven’t seen that many BPM projects utterly fail. In fact, I can probably count the failures on one hand. Instead, BPM clearly involves a journey, and sometimes BPM projects and even BPM programs stall out because the organization hasn’t matured its understanding of BPM and/or in its in-house capabilities to deliver business process change across the organization. Companies sometimes take a long time—too long—to move through the maturity phases so they get from implementing individual projects that provide good but limited productivity/efficiency gains to instead tackling true transformational initiatives that go to the heart of business performance.

    I’ll take a detour here for a moment: The one BPM project I know of that officially “failed? in the eyes of the organization surfaced several years ago. The BPM project leaders said something like “our BPM project has failed and we don’t know why or what to do about it.? The reason for failure was crystal clear. This organization had spent years (maybe 2-3?) modeling their processes, which is way too long for a project to be successful, and then after they moved to implement the process model, kept asking their BPM suite vendor to make custom changes to the code. The custom changes had gone on for about 2 years and the vendor was charging a fortune. I was aghast. No wonder that project failed.

    I don’t have many other examples that dramatic.

    But let’s say that an organization’s BPM initiative suffers from certain problems, such as not delivering as much business value as expected, or taking too long to complete a project, or providing limited value because it was just an isolated pocket of the organization. These are some of the common problems I’ve heard, but I believe it’s not so much failure as it is getting stuck in the business process improvement/transformation maturity life-cycle and needing a kick start to get going again. Also, failure is in the eyes of the beholder so one project team’s success may look like failure to a very senior exec who had much greater expectations than were delivered.

    Some reasons BPM projects get stuck include:

    • Taking too long to model processes – It’s an age-old problem, but lots of project teams get hung up on modeling the “as is? process by spend months and months trying to document it. Then they spend more months on the “to be? process. The time spent on the “as is? and the “to be? should be measured in weeks. Here’s why: the whole point of BPM is continuous improvement. Once the process is up and running, you can make incremental changes as often as you like (most companies make small changes every week to two weeks) and you can come out with new process versions every 3-6 months. To spend loads of time on modeling points to a misunderstanding of BPM’s greatest value proposition—continuous improvement.

    • Not knowing where to start—The Brits have a great expression: “how long is a piece of string?? BPM reminds me of that saying. Specifically, ?what is a process?? Is a process a full scale, end-to-end cross-functional process like order-to-cash, or is it a subprocess of that cross-functional process, like production, or is it even smaller than that? In other words, how long or how big is a process? It’s hard to know the best scope of the process to start, and if you judge it incorrectly, you can get stuck. Tackling a big, cross-functional process without a lot of process skills, without significant executive sponsorship and some smaller successes under your belt means you are living dangerously. On the other hand, tackling smaller processes over and over again will only give you incremental improvements that don’t impress senior execs. I think figuring out the size of processes to tackle in relationship to your sponsorship, strategic goals and process skills definitely becomes part of the BPM maturity life-cycle to go through before you hit the ultimate stage-- business transformation.

    • Having IT drive the initiative—We see this all the time, and I can see why it happens. In many organizations, IT understands the potential that BPM offers, and IT professionals want so badly for someone in the business to pick up the BPM mantle. After fruitless attempts to get business buy-in, some visionary IT leaders try to make BPM happen by driving it from within IT. This is a tough, tough road to go down. BPM is BUSINESS process management and requires a business champion and clearly defined business outcomes and key performance indicators. I can empathize with IT champions who want to drive BPM initiatives, but getting a business partner and business champion remains a prerequisite for not spinning your wheels.

    • Not having a strong process improvement methodology –Business process management is a discipline, not just a technology. The discipline is grounded in Continuous Process Improvement. But for the discipline to become a reality, it requires tools and a methodology or multiple methodologies. Organizations that have gotten to a business transformation level consistently report that they’ve developed a solid understanding of Lean and Six Sigma, and when and how to apply them. Many successful organizations report they developed their own home-grown combination of Lean + Six Sigma.

    • Creating a BPM center of excellence—A BPM CoE is a means to an end, not the end itself. But, it’s hard to over-emphasize the importance of putting your core business process improvement skills in a central group (or a bunch of distributed groups if you are going for massive transformation up and down the organization.) A CoE helps nurture and grow more process skills, which is vitally important because limitations on the number of skilled people can limit the pace of BPM adoption. The BPM CoE also becomes a way to gain leverage; many CoEs loan experienced staff to project teams within the business units, which then accelerates cross-training and building process skills throughout the business.

    There are many other ways that BPM projects get stuck, and fortunately, we know lots of best practices for getting the most out of your BPM initiatives. We will discuss many of these best practices at our Business Process and Application Development Forum in Washington DC on October 7-8. Please come join us!

    I want to leave you with one critically important idea. Change management. No matter who I talk with, or what size organization, change management always surfaces as the #1 problem. People don’t like change, and BPM requires a lot of change at all different levels of the organization. Most project teams struggle mightily with the change management part because they don’t have skills in this area and they don’t know where to turn to for help. Here’s a secret: the change management experts in your organization probably live in HR. Get them involved and it will help a lot.

    - Connie Moore, VP & Research Director, Forrester Research

    • Thank you Connie for addressing the myth that BPM projects are doomed to failure. Your reponse is welcomed by those of us that have seen many succesful BPM projects that deliver real value to customers.

      I agree with you on change management. We've identified it as the no.1 critical success factor for only for BPM projects but any Enterprise Application. Make Change Management as important as Project Management and the technical aspects of the project.

    • Sorry, Connie, what - precisely - do you mean by BUSINESS process management, in contrast to Business process management?

    • I think Connie has hit the nail on the head. Those that are saying "BPM has failed" are ignoring the many projects that have been successfully implemented. And the question was in relation to projects, not "BPM" as a concept.

      I've seen so many BPM projects succeed, compared to other projects that engage IT, that I find this question-phrasing puzzling. I think without citing some research about percentages of failure, and definition of failure, and definition of success... It is hard to consider the question in a neutral, objective way. (I say "engage IT" because BPM does, typically, have to engage IT as well as business).

  • Connie, thank you for taking the time to expand on all of our points in a comprehensive, articulate manner.

  • My experience in managing and architecting BPM projects taught me that Change management and Business Analysis are key to the success of any BPM project. If you don’t have these two things right, its most certain that the project would fail to meet business requirements, even if it hit production.
    In most the cases BPM projects radically change the way business operate. Its human tendency to resists change. When the business user resists changing to the BPM way of doing business, the BPM project takes the hit. This is another major reason for failure.

  • user-pic

    Did you ever imagine that a BPM project to be successfull must have some kind of
    guidance, or follow up? If your employees know the process, know their tasks, so why
    they aren't doing them? I think this is a real easy answer: you don't have the
    plataform to make you process running, where everyone knows exactly what they have
    to do, they have access in just one place to all the information to acomplish their
    tasks, and everyone knows what's the exactly point where the process stands.

    If you check this company that launch at Demo (www.demo.com) this tuesday
    (http://www.demo.com/alumni/demo2010fall/219456.html), maybe they have the
    solution, or part of it, to make BPM Projects to work. In fact ActionFlow
    (www.actionflow.com) allows you to buy some predefined BP that others have done and adapt them
    to your company's reality.

    I think it worth to try!

  • No one blaming BPM - the very conception - for BPM-project failure?
      ?!?!?
      Ok - I'll step in therefor!

  • I fully agree on most of your positions, in particular about the need for commitment.
    From our experience, the major mandatory success factors include:
    - Awareness and willingness to embrace the BPM by the high level management and by the lower level roles that are requested to provide the requirements and the feedback. Otherwise, BP analysis leads to useless results.
    - Quick prototyping and feedback collection cycles. Although customers were able to read and discuss the process models (e.g., BPMN), they weren't actually able to focus on the actual issues at the modeling level. Several processes issues were identified only through feedback on the running application prototypes.
    - Separation of concerns. Also in BPM projects, BPM is not everything! BP engineering, BP modeling, Master Data Management, Application modeling, Enterprise Architectures, ... must be considered in orthogonal and integrated way, thus allowing different roles in the project to address the various concerns.

    We shared our thoughts at BPM 2010 in Hoboken, NJ in these days. A slideset is available here:

    http://www.slideshare.net/mbrambil/web-ratio-bpmindustrialcasesbpm2010

  • Uh, I don’t even know where to begin on this. Connie has provided the usual insightful and competent response but this is one of the few occasions where I find myself in disagreement with her (sorry Connie, but I’m sure that you’ll find it in your heart to forgive me … eventually :-))

    First off, I think that BPM has not delivered. This automatically begs the question of ‘delivered what?’. Well, what are we talking about here? It’s BPM, Business Process Management, the management of business processes.

    Regardless of your personal preference on how to manage processes (hands-on, IT supported, automated etc.), any qualification of successful BPM implies that you actually intent to manage your processes. Note that I’m talking managing and not automating processes. This to my mind is the ultimate benchmark for BPM, though I accept that it’s a minority view. If you intent to manage your processes, and there are good reasons to do so – after all, businesses create value through processes -, you should see some kind of concept or strategy on how to manage processes. (Maybe process management philosophie describes it better).

    Just like Connie, I’ve been involved with first workflow and later BPM for a large part of my professional life, but I have yet to come across a company in which senior management has a (how ever which way) defined view on how to manage processes. What I do see time and again is a nearly schizophrenic approach in that processes change projects are attention grabbers but their results are not taken notice of. Commom understanding seems to be that processes are a one-off affair: Once you’ve got them you don’t need to care (i.e. manage) about them – until the next time, when you initiate the next project cycle. All this smacks of seen to be doing something instead of using processes (projects results) to create business value.

    I suppose what it comes down to is the lack of a BPM mindset. If you don’t understand what you’re doing and above all WHY you’re doing it, chances are that you’ll fail plus you won’t even understand that you’ve failed.

    (Hmm, that makes me sound like a clinically depressed pessimist, let me assure you that I still retain an honest smile on my face and in my heart :-))

    Maybe it’s the fear of transformation. Connie is so right in mentioning the importance of change management because when all is said and done, BPM implies change. Processes change, process performance changes, processes have different impacts (on other processes, IT applications and people) over time… This is why we need to manage them, to stay on top of the inherent internal dynamics of processes.

    Process modeling? Yep, another one of those figleaves to cover inadequate process achievements. (“We do BPM? “Oh yes?? “Yep, we’ve got tons of process models? “Well, maybe you should open a gallery?) Of course, I’m not disputing the value or even the method of process modeling. But for whatever reasons this has turned into art for arts sake and the whole discussion about paints and brushes – BPMN, BPEL etc. – has done nothing for better managing processes. At best we have created better design and in very few cases even better processes, but have we learned to manage them better?

    Again, my feeling is that we have forgotten the WHY. And lets not forget, when businesses need to invest 30 to 40% of project time on discovery, it does beg the question of if we’ve even learned to manage (update, stay-on-top-of) our process models.

    I must admit, some of my views may be influenced by the results of the Process TestLab (http://ptl.taraneon.com). This is where we check (among other things) process designs for errors. Since the lab was opened 6 months ago, we have collected the data from the various tests we run and they do not make for a good read. When more than 80% (at last count) of the processes checked contained logical errors, you suddenly understand why the final result, the implementation of those processes, is not what you bargained for.

    But in focussing on BPM we should be asking not about the models of the actual processes, but about the models which describe how processes should be or are managed. Ask the average senior manager – who usually demands nicely colored models to show off his area of responsibility – if his management process is documented and he will tell you that he doesn’t need that sort of thing, it’s all down to experience in his case.

    So, after this rant-de-force, who is prepared to tell me that
    • Our processes are managed better today with the availability of BPM?
    • Our enterprises have really become more agile, more flexible?
    • Our processes have become more application independent and quicker and easier to adopt to customer requirements?
    • Standards like BPEL and BPMN have facilitated the transfer of business requirements into IT?
    • That the quality of processes and process management has improved?

    Yes, there are ways to adress these issues and to achieve these goal, but as long as we insist on this make-believe approach of ‘easy BPM at the push of a button and the purchase of a BPM system’, I fear we’ll never get there. Managing processes is a complex business and anyone reducing it to projects needs to be very lucky indeed. BPM is an intellectual challenge and not a technical one. Have we got the right people with the right attitude to make it work?

    If anybody can convince me that things are indeed better than they seem to me, I’ll bow my head in shame and apologize (from a safe distance).

    Thomas

  • Any BPM system/solution (an enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio) is, by definition, a socio-technical system. One of the main difficulty of socio-technical systems is “how you do something is sometimes more important than what you do?.

    So, a BPM project has certainly a daunting mixture of mutually enhancing challenges (thanks Thomas).

    1. An architectural challenge: The architecture of a BPM system/solution is VERY important. It should be done in some extend (artefacts, relationships between them, principles, etc.) before even talking about BPM tools and modeling of business processes.

    2. A change management challenge: We have observed that implementing a BPM system/solution requires a lot of communication with practically _everyone_ within the enterprise, and everyone should be treated as a stakeholder of the BPM system/solution. Each group of stakeholders has different views, different concerns and a different understanding of the BPM system/solution. It is necessary to explain to each group of stakeholders how their concerns will be addressed and how their current working practices will be changed for the better. (Sorry Connie, but people like some changes). A hint: good architecture will help with this challenge.

    3. A technical challenge: If you managed to properly address the two previous challenges then this one should be easy for you.

    Thanks,
    AS

  • Yes. Many IT projects fail and so do BPM. But many ought to be considered failures and are still forced on the business. Others failed despite good work because perceptions went wrong. BPM as the principle perspective how to structure a business is in my mind as practical as is OO programming and democracy. It is not perfect, but it has the least negative side effects.

    The idea as promoted by many BPMS vendors and methodology consultants however that the complete operations of business can be encoded into flowcharts is utterly ridiculous. Process is not about flows but about people servicing people. People remain the asset. When that is ignored the projects pop! Unless IT can step back after setting up a BPMS infrastructure and let LOB do processes their way, there is no process maturity. Enough. I have written more on various blog posts, should you be looking for more aggravation.

    http://isismjpucher.wordpress.com/2010/10/21/process-is-conversation/

    http://isismjpucher.wordpress.com/2010/10/27/lipstick-on-a-pig/

    http://isismjpucher.wordpress.com/2010/10/04/the-problem-with-bpm-flowcharts/


    Peter Brand and Thomas Olbrich: Congrats for your guts to speak up.

  • Thanks, Max, I do appreciate your support!
    But why 'guts', when it's about research results?
    Also, 'speaking up' seems to refer to someone's opinion.
    Not to profound empirical and theoretical enquiry.

  • Missing from the bulk of responses is that all processes should have a clear relationship with the strategic objectives of the enterprise and related KPIs. Sustainable and consistently executed processes generate outputs which then modify outcomes. If these outcomes are not linked with the strategic directions of the enterprise, why is the enterprise executing such processes? If you apply BPM to an enterprise whose processes are not linked with the strategic directions of the enterprise, BPM will fail.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT