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

How do you avoid 'scope creep' with BPM?

Vote 0 Votes
Awhile ago I asked, "What are the costliest BPM mistakes?"  One of the main answers was "scope creep," so what's the best way to avoid "scope creep" with BPM?

7 Replies

| Add a Reply
  • BPM is really good at scope creep, just because it can be so hard to tell where one process ends and another one starts. We've been great as an industry selling the idea that a process can cross organizational boundaries and is more than a simple workflow. This unfortunately makes it harder to say where and when to stop.

    How to avoid scope creep? I still think that applying an agile development approach to the implementation of BPM solutions is the answer. The first week, you understand the full, possible breadth of the process, and the priority parts of it. The next week you are already focusing on the details of the most important parts. You iterate, to incorporate adjoining sections, and to refine the parts you have already completed.

    Managing scope becomes easy. Your scope is boxed by the amount of process you can feasibly implement and test in the time you have available. This is based on the complexity you experience during implementation, not some up from design 'guesstimate'.

    I know that agile methodologies don't work in every environment or for every business process problem, but they have been shown time and again that they can produce high quality solutions within the bounds of an available budget.

  • Understand that there will be SOME scope creep, i am one that believes it is inevitable. Your goal should be to understand that this will happen and through correct planning, prioritization and scheduleing minimize the impact on the project. Also be prepared to get formal sign off on all scope changes and document their impact on the project, its listed deliverables and schedule impacts. However you can work to try to elimnate scope creep through some simple things

    1. Thoroughly understand and document the project charter/vision/scope/sucess criteria. Clearly define all deliverables and how those deliverables map back to business priorities.

    2. Ensure that the scope is reasonable

    3. Ensure that the problem you are trying to solve or process you are trying to automate is very well defined.

    4. Ensure you have involved all stake holders not just management but also involve the "end users" who will most likely be responsible for participating in the process.

    5. Conduct small workshops which each group that will go through the process step by step to ensure all parties fully understand the process and what you are trying to do with the project.

    6. Get buyin and sign off from each group prior to starting any work.

  • I love this question because it reflects perfectly the Newtonian/Cartesian thinking that brings many business process initiatives down.

    When executed correctly, BPM is NOTHING BUT scope creep. Everyone talks about the business process improvement cycle which is a continual assessment of how well the process is running, and trying new ways to improve the process. Done right, this involve adding things to the process that were not conceived of when you started.

    How does one define "scope creep?" It exists only in a development method where you (1) define the perfect process in complete detail, and (2) implement the process without any change to the original design. If at any time you change the original design, that change is called "scope creep" by those who held the belief that the original design was perfect. If you are worried about scope creep, then you have bought into the idea that a business process can be predicted up front, and that you have found a process that needs no improvement -- a position that strikes me as arrogant at best.

    Organizations are complex. The marketplace that the organization competes in is complex. And, as you implement a business process, it changes the organization, often requiring further changes to the business process. All of this conspires against the original process designer, making the process unpredictable.

    Scope creep is actually your friend if you properly anticipate it. An Agile approach forces you to implement in small increments: keep the original scope very small and get it into the hands of the people quickly. Allow give plenty of room for re-implementation, rethinking, and redesigning. Measure how well the process is working, get feedback from the users, and focus on the hot spots. Release improvements regularly: every few weeks. The point is that the organization is changing at the same time, so every release is measured against the organization that currently exists.

    A quote from Ilya Prigogine: "The future is uncertain…but this uncertainty is at the very heart of human creativity."

    My recommendation: if you are working with people on a BPM project who are worried about scope creep, distance yourself as quickly as you can from these people who obviously don't understand the essence of BPM.

    http://social-biz.org/2011/05/11/its-all-newtons-fault/

    (After re-reading what I wrote here, I realized that I am running against the multiple definitions of BPM problem. Some see BPM as a process involving people and my statements apply to that. Some see BPM as a way of "orchestrating servers." For this latter group, a process between servers IS predictable, and thus scope creep is a real problem to avoid, just like any other software development project. My comments are intended for the first meaning of BPM.)

  • Hats off to Keith, I think he's spot on.
    Only thing I'd point out is that there's a difference between BPM in an operational sense and BPM projects. I do believe that BPM projects often enough have to battle with scope creep because for many it's a journey into the unknown - hence the requirement for discovery. At the same time, a project has to have a pre-defined outcome, deliverables etc. So there has to be a cut-off point at some stage.

    BPM in an operational sense should very much be the opposite: Free-flowing, unrestricted, always on the move, following the processes.

    Can't help but wonder why many are doing it the wrong (?) way around: Extending scope when they should limit it during projects and limiting scope when they should take a laissez-faire approach during operations.

    Thomas

  • Scope creep is very possible anytime something complex is addressed. The team directly involved in the project first needs to be supported by an executive sponsor that has given them the necessary authority to run the project based on the approved plan. Then the executive needs to allow the team to work without meddling and provide the necessary support and air cover. The team then must spend the time up front to clearly define the process and the specific elements of the process that will be managed and tightly define the desired outcome. With continuous support from management, laser focus on the defined process elements and outcome, scope creep can be avoided. In short, planning, focus and executive support not meddling) and key requirements for success in avoiding scope creep.

  • Apart from having to define what is meant by 'BPM' (methodology or system' then one have to define what is meant by 'scope'. Having a scope basically means you have a project with start and finish. The one and only way to avoid scope creep (BPM or not) is to have defined the test criteria that sign off the project. Don't change the tests and there is no creep.

    Installing a BPMS should have such tests and that would most of all include the backend interfacing (SOA or not). It makes no sense is to develop processes in a project because when the project is over there won't be ongoing improvement. So the BPMS project needs to test if business people can create and maintain processes and related resources themselves. Once they can, the BPMS project is completed. No creep. Most BPMS projects fail to deliver that and this is why they have all endless process implementation creep ...

  • Just to add to what Max mentioned in his comment:

    There is a difference between
    - projects to kick off BPM as a topic (with or without BPMS)
    - projects to implement a process (with or without BPMS)
    - operations of processes
    - operations of BPMS
    But maybe that could be a topic of a future discussion.

    BtW: Is it just me or does trying to manage processes on a project basis sound stupid to anyone else as well?

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT