When looking at BPM there appears to be two distinct worlds Pegasystems Inc. and one that is more standards-driven that includes vendors, such as, IBM, Appian, etc.  BPM using Pegasystems’ PRPC versus BPM proscribed by this latter set of vendors represent two very different philosophies on how to implement BPM systems. However, I would say that the one thing that all vendors appear to agree with is that an enterprise-grade BPMS is a truly disruptive technology, since its tactical mission is usually to:

• Extend the functionality of existing apps, 
• Enable disintermediation between applications, 
• Tightly-integrate processing gaps among disparate applications
• Provide opportunistic business application behavior that takes advantage of new technologies and techniques in order to deliver superior functionality

There are many ways to ‘do’ business process improvement projects. It’s best if the company has a methodology from BPM, Lean, Six Sigma, Reengineering or some other methodology. Here’s the one I use, starting with selecting the project and ending with monitoring and sustaining the project; ‘doing’ the process improvement project means completing the section in the middle from Chartering and Staffing to Implementation Plan.

Companies use a number of methods to conduct the BPM project from using a Six Sigma Black Belt as an expert, to having a Business Analyst do interviews with subject matter experts and developing the as is model and to be map, to using different half day workshops for different phases of the process with the appropriate stakeholders. The one I highly recommend and have used with over 100 different processes is a team-based method.

Anyone who has worked on waterfall projects knows the challenges:  The lack of communication between the business users and the developers; the predetermined (and immovable) requirements; the quality issues that are not evident until you are too close to the release date to safely address them; and the frustration of having to wait months (and sometimes years) before your efforts result in a live working solution.

When you make the move from waterfall to Agile projects, you have two choices:  You can choose to either block out your waterfall experience altogether (like any traumatic event!) or you can choose to leverage your experience to make yourself an even more effective Agile team member.  Here are three ways that you can use your waterfall experience to your advantage: