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 scope for a BPM project?

Vote 0 Votes
Suggested by Emiel Kelly: What is the ideal scope for a BPM project?

12 Replies

| Add a Reply
  • What is really ideal is 'no scope creep'. Scope creep has destroyed many projects...

  • To quote Michael Jackson: "Don't stop till you get enough."

    On a serious note, start small, well defined with a goal in mind. Loose projects with wishy washy strategy are doomed to fail because you have nothing to aim for, no measurable way of defining success.

    If you can't define your BPM scope in a single sentence and know you can measure the business outcome of that success then you'll probably fail.

    Then basically learn, adapt and radiate for future projects.

  • Although I discussed this with Peter, maybe scope is not the right word.

    Actually this question cam to me in an earlier discussion (I think it was about the do's and dont's in an bpm project. but what never became clear to me (you could tell from the reactions in the discussion) what a bpm project is.

    Is it installing a workflow system, modelling processes, ghetting compliant, becoming process aware etc.

    I see so much misunderstanding about what a bpm project is, so maybe a better question would be:

    When you take your definition of a project, what will be the result after the project has finished?

  • Excuse for the typo's. I am painting my house and the paint is drying.....

  • Personally I really like to start with a budget and then find the best scope to fit that budget. It is a nice disciplined way to start a BPM effort- and prevents the temptation of boiling the ocean because the budget is fixed in advance.

  • Before serious project starts there are 3 essentials

    1. Agree the objectives/outcomes/goals i.e.- what are "we" trying to achieve.
    2. In business language with users workout step by step who and what is required to make it happen. Encourage new ideas there are no constraints.
    3. From 2 work out estimated cost. A good guide would be work out number of UIs (including reports, maintenance forms etc) needed. That number becomes the number of man days to build application. If very complex like a configurator or means testing or heavy reliance on accessing legacy it may be longer - but such issues identified at this stage not later!

    At this point a fixed price can be negotiated contract agreed and build starts mirroring exactly what has been agreed. First cut for feed back in say a week to show users their ideas coming to life!

  • Hmm, it appears, on the surface at least, that there is general agreement -- define goals, outcomes, and measures; have a schedule; avoid scope creep; and stay within a budget.

    Sounds very similar the old PM adage "Scope, schedule, budget -- pick two!"

  • Would be one where the business problem is clearly defined. One where the business understands the cost of not solving the problem and where the solution proposed costs less than not doing anything and meets the expected ROI for the business.

    Once you are sure of these things then you will know that you are in a good place for success.

    (I guess my words are similar to Scotts suggestion above - but perhaps I am suggesting that budget is a moveable object and is really a case of ratio of spend to gain)

  • BPM isn't CRM, ERP, or the other TLA big-box software products. BPM solutions can be deployed tactically, and then tied together for additional strategic leverage.

    As a result, most of the time the scope of any BPM effort should be: as small as possible to achieve the desired outcome. If multiple positive outcomes are sought, divide and conquer. Breaking the challenge up into digestible fragments is the key to solving nearly any problem; BPM is no different.

  • very interesting discussion and thoughts.
    sometimes from the program management standpoint, its also the 1)road-map set from an enterprise perspective, 2)the business sponsors 3)stakeholders and 4)resource pool availability, play a key role directly or indirectly in defining the scope and ground for a BPM implementation in a customer landscape.

    secondly, BPM is just an enabler and it should not be used as a tool to automate every other process just with the need to widen the scope of implementation.

    The ideal scope of a BPM project can actually be seen as "building a house" - to start with :
    - is the plot in a residential area (i.e where does the project stand in terms of the enterprise roadmap)
    - will more work and money be invested in clearing the rocks/ground for construction.(i.e landscape details and feasibility study vs costing)
    - what is the budget for building the house(i.e project budget)
    - house plan and architecture design (discovery sessions to understand the landscape and design better)
    so, to enjoy the shade of the house, all the attributes go hand in hand right for the organized approach in scoping till the completion of construction.

Add a Reply

Recently Commented On

Monthly Archives