Resolved
3 votes
Very simply, in your experience, what is the first indication that a BPM project is going to fail?
Tuesday, August 05 2014, 09:45 AM
Share this post:
Responses (14)
  • Accepted Answer

    Tuesday, August 05 2014, 10:40 AM - #Permalink
    Resolved
    3 votes
    Religion believes in right and wrong. But there is no place for it in business. Nor for its love child – success and failure. The binary mindset - Yes/No with no options of "Maybe" or "a good first step" or "It's good but it can be better still"- has been the death of many companies. There is another mindset to get rid of too. The Project one. BPM is about continuous improvement – P stands for Process, not for Project, and processes, in theory, go on forever. There are some Fool’s Mate failures – you know – really stupid errors which guarantee it is a waste of everyone’s time. The first is when someone talks about “implementing BPM”, like screwing in a lightbulb. Fit and forget, without mindset change. The second is when they appoint a Project Head. They are going to try to fit it in a box marked Project. The third is when the CEO says “Collaborate with XXX on this, will you?" If you have to be forced to work together on a top-down directive, it won't work. If someone gets so excited that they say “work with me on this and we’ll take it to the CEO”, it has a chance of being effective. But the real meat in this question is the definition of failure. To me it is… When the process doesn’t get markedly better every month after the BPM team has gone home. When the process doesn’t adapt to a change in the needs of the customer. When the people operating it aren’t constantly thinking of ways to make it better still (and have the ability to implement them). Most BPM experts are long gone before those three failures happen, busily writing it up as a success story for their website.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, August 05 2014, 10:43 AM - #Permalink
    Resolved
    0 votes
    When you hear developers say, "We don't have time to do it right." Translation: "We have plenty of time to do it wrong." Seriously, the answer is when they shortcut the requirements definition and go to programming prematurely. Case in point, the Obamacare system which is now approaching $800m in development costs.
    • Scott Francis
      more than a month ago
      right, blame it on Obama. I'm going to try that on a failed project some time and see how far it gets me.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 05 2014, 10:57 AM - #Permalink
    Resolved
    3 votes
    When they first start calling it a "project".
    Like
    1
    • Emiel Kelly
      more than a month ago
      If I wasn't on Holiday, that would be my answer!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 05 2014, 11:20 AM - #Permalink
    Resolved
    2 votes
    "no architecture", of course! Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Amy Barth
    Amy Barth
    Offline
    Tuesday, August 05 2014, 11:23 AM - #Permalink
    Resolved
    2 votes
    When the customer refuses to listen to the experts they have hired to run the BPM project and demand a waterfall process. It's never a good sign when waterfall is the preferred methodology (or when your clients refuse to listen to experts).
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 05 2014, 11:27 AM - #Permalink
    Resolved
    2 votes
    When "IT" gets involved too early. Business really gets it; old IT does not they do not understand how people work and see nothing but problems?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 05 2014, 11:55 AM - #Permalink
    Resolved
    1 votes
    The first sign of failure is: you need a large BPM implementation team with lots of outside consultancy. (5-25 man-years) Second sign: there is the demand for short term ROI Third sign: non-technical business people cannot create and adapt processes themselves. (No, its not BPMN ...) Fourth sign: you need to setup a large process improvement bureauracy. Fifth sign: there is no adoption unless the executive champion enforces the use of 'tools for fools'.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 05 2014, 03:04 PM - #Permalink
    Resolved
    1 votes
    The very First Sign when we think the Project will FAIL is ....
    • ......the moment when we figureout there is no Plan laid down for implementation or driving the program - with defined checkpoints and KPIs
    • ......the moment when we have started with the implementation and then think about how the data model, design and architecture should have been crafted
    • ......the moment we try to customize and try to make it a "workable solution" - not considering if it is the ideal way and not thinking through from a futuristic perspective.
    • ......the moment we try to FIX / ADDRESS the ISSUES in the current state, which can even become a BLUNDER in future (not thinking through from a performance standpoint but just living with the system). It is as good as having the Process/Application under Ventilators in an ICU
    • ......the moment when we just consider the "BPM Implementation" "as yet another project leveraging a tool"
    • ......the moment when we try to "force-fit" the requirements with the Tool that is available in the Enterprise Landscape - doing no justice to the functionality
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 06 2014, 10:26 AM - #Permalink
    Resolved
    4 votes
    I agree with what so many have observed: projects rarely fail for "technical" reasons. Usually, things go seriously awry when you have sponsorship problems, lack of clarity around roles and responsibility, or breakdowns in communication. Doug Kra, Pega's SVP of Customer Success, recently wrote a really interesting blog on how to combat these issues in larger projects. I suggest taking a look here: http://www.pega.com/community/pega-blog/delivering-on-the-vision-the-power-of-multi-level-governance - Ken
    • BPM Mentor
      more than a month ago
      You definitely got the answer: sponsorship problems, lack of clarity around roles and responsibility or breakdowns in communication! Thank you!
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 06 2014, 11:06 AM - #Permalink
    Resolved
    2 votes
    There are so many good answers above. But I want to take the question at its basic meaning - when do we first see a BPM project failing - and yes, it is a project at the beginning because we are studying it and improving it. First would be a Process Owner who has no interest in the process and effort. I was worked with a team who could not get more than a 10 minute meeting with the Process Owner. Clearly we should not have been working on this process. Another would be not selecting a team that represents all the employees/stakeholders who do the work, including IT not developers but people who know how systems work with the process today and understand the capabilities of technology). And if you get these team resources, they have to be committed time and emotionally to work on the process/project. Don't start with one hand tied around your back, or you'll experience a slow death.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 06 2014, 11:36 AM - #Permalink
    Resolved
    2 votes
    Someone says "Hey, we got this free BPM system bundled with that other product we bought, why don't we use that?"
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 07 2014, 11:06 AM - #Permalink
    Resolved
    1 votes
    I think this link does the trick: http://bpm.com/my-bpm/forums/is-there-ever-a-reason-to-use-waterfall-methodology-in-a-company-today We know a project is in trouble when the project team or the sponsors start engaging in revisionist history or fail to back up their words with deeds. "This is a critical project" followed by "we're going to need to reduce the budget to fund an overrun in the omnibus 123 project in another group" ... oy. And when we give advice to the customer that is sound advice, and they say "I know you're right, but I can't do it that way, I have to do it this other way because that's how we do things here." or "I know you're right, but you're describing the gold standard and I just need a B-team solution." or "I don't need the A-team, I just need some developers" Wow. Those statements are death to BPM projects. The mistake that these people are making is thinking that "B" developers just take longer to write the same solution, at a lower rate per hour. "5 B developers is better than 1 A player." What they're misunderstanding is that every line of code is an obligation to maintain in the future. 5 B-class developers will write a lot more bad code than one A player. And all of that bad code will cost you in the future - not just for the current project but for the future. A good test of this attitude is to ask if we could get 5 b-player PMs or directors or VPs to replace them. Surely that would be better for the business, right? : )
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, August 10 2014, 03:19 AM - #Permalink
    Resolved
    1 votes
    There is no such thing as a BPM Project! I have been involved in many business process projects, around the world and where the company has seen amazing results, and many of these have been rescue missions. Time and time again we have walked into a business outcome driven process project where the traditional SI or the internal IT department (the original custodians) has seen this is a BPM tool project. This is the first sign that the BPM project is going to fail. There is no such thing as a BPM project! There is a only a process improvement project, ( well I tell a little white lie - there are instances where companies are implementing BPM applications, but that in its self is not a BPM project but more a software implementation project). Process projects fail because of poor scope, poor delivery of the process improvements and a severe lack of the consideration of who the process content needs to given to and their needs. Every time I ask, at the very beginning of a project, "Why are you doing this process project and who is it for?", I am continually amazed at how narrow the SI or project team think the audience for the process changes are and the fact that there is rarely any real consideration for the capture of the end-to-end process. Let's consider when a company is considering to get efficiency from optimising processes through automation. How often is the end result of this exercise just a bad process performing quicker. The cause of this is that the project team has entered the project with the mind set that this is a BPM automation need versus the real need to map the entire end-to-manual steps, in a process language that is understood by all stakeholders (not just the BPMN junkies). Having a clear view of the end-to-end manual process gives you a much clearer understanding of what activities 'actually' need automating.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 06 2015, 02:59 AM - #Permalink
    Resolved
    1 votes

    When we give sound advice to our customers, and they say “I know you’re right, but I can’t do it that way, because that’s not how we do things here.”

    • Bogdan Nafornita
      more than a month ago
      Rings a painful bell, Alisa...

      As a CFO, I was being audited by an internal auditor at big-three-letter-IT-US-multinational and she was looking into the official expense reporting process, to which I have been adding a few improvements and simplifications, at the same time improving both compliance and process time.

      She asked me to revert to the old process. I objected with all possible business and control posture arguments. She replied to me: "I know you're right, but this is (big-three-letter-IT-US-multinational)"

      So sad.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016