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

What is the ideal speed of a BPM implementation?

Vote 0 Votes
From this blog by Scott Francis, who writes, "Get your project into production within six months.  Every day after that is on borrowed time and is at greater risk, like penalty time in a soccer game."  What is your rule of thumb for the length of time for kicking off a BPM project?

10 Replies

| Add a Reply
  • I know it's getting boring, but are we talking BPM (is not a project in my opinion)or BPMS?

  • +1 Emiel

    Scott talks about a technical implementation, which I have to agree, 6 months or under, anything else and to be honest you've chosen the wrong SI or Vendor and are falling behind.

    But it all depends on just what the scope of the project is in the first place. An enterprise transformation is going to take longer than a point solution.

    However, talking business implementation now. It takes as long as it takes. I'm afraid to say there are just too many facets such as compliance, governance, cultural impact, education, capability and maturity to take into account for a BPM project to be rushed to the finish line. You can either tackle all the hurdles and finish when you are ready or make a dash for the line and skirt round every issue for someone else to resolve. Like the sport, you'll pick up penalty points for cheating only in business it's fines and your job.

  • Ok BPMS it is. The ideal answer would be 0 seconds to me ;-)

    Taking the risk of ending up as 'Doubting Thomas' again in real life there are so many aspects to take into consideration:

    - There are so many software things sold as BPMS, what is the functionality we are talking about?
    - Is it just setting up the platform?
    - Is it implementing 1 process, 10 or all in the BPMS?
    - What kind of processes are we talking about?

  • Seems pretty obvious to me that we are talking about getting the BPMS system installed PLUS the "main" process or processes automated. I totally agree with Scott's blog and think the point is rather simple - there is a basic tolerance threshold in most projects and 6 months is a pretty good rule of thumb. We could get a little more complex and say there are 3 rules of thumb - 2,3, and 6 months. In this case I would recommend sizing up the client before hand to understand where the threshold lies, and then make darn sure that you fall below that threshold. The threshold will be based mostly on maturity, "political risks," past experiences with enterprise level software, etc.

    One of the main reasons that agile and continuous programming techniques have become so wildly popular for software programming is because they do a great job of breaking down projects and keeping expectations under control. Short 2 week sprints of work are simple and easy for everyone to understand. It just makes obvious sense, and I am amazed that more BPM implementers are not seeing the writing on the wall and moving faster in this direction.

  • If using Definitional Object Model Development that uses a declarative technique so "no code" then there are 3 actions to see delivery of a working project.
    1. Discovery. This is where users and management agree what it is that needs to be addressed and how. It need not be too detailed but a step by step who or what needs to happen to achieve the individual goals and the overall objective. This is a business driven discussion (IT do not need to be involved indeed best if not) and articulated as such in business language or maybe quick sketch of the actions involved. This should be part day exercise maybe longer if multiple departments involved maybe even external parties.
    2. First cut/prototype. The build then starts can from the discovery discussions and will track exactly as users/management required. It takes place in a Graphical Builder/Designer and readily understood by all interested parties. This can take place in days without any sophistication in user form design At this stage it would be identified what information is required to and from legacy and “IT” can be informed of these requirements that can be called by the process or as required by the form for say mash ups. If a big project then best to cut into manageable “chunks” and allow users to see within memory of discussions and get feed back with change readily supported. At this point once users see their process coming to life then new energy tends to see better ideas and so an iterative build takes place. A good estimate to get to a near final cut is take number of forms/reports required and that will become the number of man day to build.
    3. Deployment. Hopefully IT have contributed to getting access to legacy and the secure infrastructure is ready. The final agreed process goes through final testing in development environment and is ready to go!

    The man day per form remains a good guide for the end to end application build but could be quicker if simple could be longer if complex but an accurate estimate should be possible at the tail end of the discovery. Whatever a reasonable sized process should be up and running within in a month maybe two (if IT can keep up!).

  • The day a project is most likely to succeed is the day on which it is approved. Every day thereafter, the risk increases. So, as Scott correctly suggests, the faster the better.

    Another thing to consider. If your BPM (OK, OK: BPMS) project is slated to take a year, you have to ask yourself why. As I've said over and over again in this forum: BPM isn't ERP. It isn't CRM. You should be able to deploy bottom-up, accumulating small victories until one day you wake up to realize you've accomplished a true corporate transformation.

  • A BPM project should apply to enterprise level requirements such as CRM, HRM, SCM etc anywhere people are at core of requirements? As for ERP if the enterprise adopts BPM principles where all source information is created then ERP becomes obsolete. Buy an accounting system if to want to keep up double entry!

  • In today's economy where even the most strategic executives are looking for fast returns, I believe that 6 months is the outside time frame for implementing BPMS and seeing results. Anything longer, again in today's economy, just won't be considered a wise investment. To achieve this, solution partners and customers should break down the implementation into measurable phases. When good times and the acute pressure on reducing costs and increasing revenue eases up a bit and the economy improves, the story could be different.

Add a Reply

Recently Commented On

Monthly Archives