Resolved
0 votes
An idea that Ian Gotts discusses in this blog about social, so when implementing a BPM project, does it still require a leap of faith on the part of the enterprise?
Tuesday, November 12 2013, 09:54 AM
Share this post:
Responses (13)
  • Accepted Answer

    Tuesday, November 12 2013, 10:02 AM - #Permalink
    Resolved
    2 votes
    No, just the usual stuff it takes to successfully deliver an initiative. Sponsorship Business participation Good project management Technical acumen
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 10:17 AM - #Permalink
    Resolved
    1 votes
    The usual stuff Patrick mentioned. Even then, domain expertise is often overlooked when looking to shave costs on the project. I can't tell you how many projects I am brought in to rescue or correct thanks to going with the 'Vendor' option or a commodity service provider. It almost always comes back to bite the firm and the vendor themselves by having an unhappy client.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 10:17 AM - #Permalink
    Resolved
    1 votes
    To paraphrase a quote about taking that leap:
    "Ultimately, when you're at the edge, you have to go forward or backward; if you go forward, you have to jump together."
    And that takes 3 of the 4 points that Patrick makes (not so much the technical acumen), starting a BPM project is a group effort. Faith is only involved when you don't actually plan and have a goal in mind and unfortunately you can't succeed with a project if you don't know what the outcome should look like.
    Like
    1
    • Patrick Lujan
      more than a month ago
      Sorry, gotta disagree on that last. "Technical acumen," "domain expertise," etc. singularly kills more BPM projects' success than all other factors I've seen over the years combined.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 10:41 AM - #Permalink
    Resolved
    0 votes
    I think the scale of the leap depends on the scale of the project, just like any other project. What benefits are you seeking or promising? What investment is required? Your faith can be supported and justified. If you're talking about putting in a BPM technology platform without any specific predicted or planned benefits, that is indeed a leap of faith, and often an foolhardy one. P.S. In all seriousness, I find that it often helps to not call it a BPM project.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 10:59 AM - #Permalink
    Resolved
    1 votes
    A BPM project is a journey of discovery and destination. Clearly, as has been said, the goal (destination) needs to be known; otherwise, you're just wandering around. However, the sophistication of the instrumentality for defining the goal (destination coordinates) and mapping the course to it (the journey's direction) have a profound impact on how well the trip can be planned. It could be argued that the principal difference between ocean crossings today and hundreds of years ago is that the instrumentality is better as is the capabilities of the ships themselves. So should BPM projects be nowadays relative to what such efforts would have been called decades past! But is this actually the case? Or has an over-reliance on instrumentality and vendor-driven pronouncements about capabilities worked against this result? For in the end, every journey is going to run across the unexpected and the non-conforming. One might even be tempted to say that unearthing this stuff (like missed requirements or technical issues) is almost as important as reaching the destination itself. I would suggest that this is the leap of faith aspect implied in the linked blog entry. Any project will encounter that moment on the journey "map" where it says "beyond this there be dragons" and have to decide what to do. The leap is to launch the project knowing that awaits regardless of what you do.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 11:17 AM - #Permalink
    Resolved
    0 votes
    I certainly does. Any technology that supports the interaction of people will naturally change the way that people interact, which in turn changes the requirements for the implementation, which changes again the way that people interact. We always talk about the "as-is" and the "to-be" vision. It is clear that "to-be" is not the same as "as-is" due to intended change to a better pattern, but what we can't precisely predict is the "as-it-ends-up". Any good BPM project will recognize that it is a journey, a voyage of discovery. Will you discover something better than you had before? That requires faith that when you get in the middle of change, you will be able to take advantage of the benefits, and to leave behind the things that do not work. It is a real collaboration, and it may lead you, as Lloyd puts so well, "off the known map". The biggest enemy is fear of failure, and that is where a healthy dose of faith can make the difference between success and getting lost.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 01:20 PM - #Permalink
    Resolved
    1 votes
    Certainly should not be. Armed with a tool that reflects how people really work and interpretation in their language to build the process will quickly remove the general fear and cynicism that come with most "IT" projects!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 01:54 PM - #Permalink
    Resolved
    0 votes
    For me - no, there should be no leap of faith, unless one believes that BPM is one of those magical, unexplainable technologies that has suddenly descended from the immortals. But, at the same time, I feel the discussion should be richer. What if, for a customer, the project requires a leap of faith because of completely different reasons from the BPM technology itself: 1/ political positioning inside the organization 2/ lack of C-level sponsorship 3/ resistance to change 4/ lack of resources for both implementation and support 5/ lack of understanding of the project benefits Does it make sense to still do the project if the customer is not ready? A possible answer is: it depends on your sales model. If you have a high-touch sales model, with sales reps visiting decision makers, running slide decks and selling big, one-time projects, it probably makes sense to invest in customer readiness. Conversely, if you have a no-touch or touchless conversion sales model, you shouldn't invest a cent in sales and just go with marketing, inside sales techniques, freemium arrangements and let the customers / employees talk up your product. At least that's what Clayton Christensen recommends and I am not going to disagree with him any time soon :)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 02:01 PM - #Permalink
    Resolved
    0 votes
    If it's your first one: sure. You may have a vendor you haven't worked with before, an untested technology, and an imperfect understanding of your business process and how it will translate into a set of BPM forms, workflows, business rules, etc. You may be uncertain as to the level of skill required on the part of your staff, or how you will divide implementation between your team and that of the vendor. You may be trying to understand the trade-offs between deploying in the cloud versus on-premises; even if you've settled on the cloud, you may be working out the difference between multi-tenant, single tenant, and business process as a service. The magnitude of the leap (on a scale of, say, hopscotch to Snake River Canyon) depends primarily on the amount of advance effort you've put into understanding these questions and the resulting level of confidence with which you embark on the project.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 12 2013, 05:41 PM - #Permalink
    Resolved
    0 votes
    If you don't understand what you're doing, it takes a leap of faith. If BPM looks like magic, its a leap of faith. By way of example, for some of our customers, they have rational and logical reasons for believing in BPM, and reams of data to support their reasons. But they have had a bad experience with, agile development, for example. And so it is a bit of a leap of faith that this NEW vendor can do agile the right way, or that this new vendor can teach them the basics so that agile isn't just "an excuse to be undisciplined." Ideally the leap of faith isn't required, but when it is, try to scope it down to as small an area of concern as possible, and then explain the path to demystifying that leap of faith ASAP.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 13 2013, 01:55 AM - #Permalink
    Resolved
    0 votes
    Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clark.
    This is the quote with which I began my book on BPM (in spanish; www.bpmteca.com). Since I read it, I always thought it was very appropriate for BPM.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, November 13 2013, 05:03 AM - #Permalink
    Resolved
    0 votes
    Sure it does, but which investment doesn't? The great thing about (most) BPM platforms is, that you can start with one simple process, make people comfortable with a new solution, then implement another, more complex ones. From my perspective, this is very common scenario and a wise one. People are usually reluctant when it comes to change something. But when change brings improvement, then its way easier to introduce another changes with the same tool. Therefore BPM(S) requires certain level of trust, but at the same time it doesn't have to be 'all in' project.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 14 2013, 05:04 AM - #Permalink
    Resolved
    0 votes
    I would add to Patrick's list a still "unusual" stuff in the BPM domain - architecture. Thanks to the nature of BPM as a "coordinator" of many things (or artefacts) within an enterprise, a proper BPM architecture helps to explicitly link and enact/animate their work together thus making the expected result more tangible and more probable. Thanks, AS
    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
277 Replies
28/09/2016
David Chassels
270 Replies
28/09/2016
Emiel Kelly
222 Replies
29/09/2016
Bogdan Nafornita
209 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016