Pretend for a moment, that you are a brand new BPM project manager tasked to head your company’s first BPM project. The BPM software vendor has just finished their one week proof of concept (where they made everything look incredibly easy) and your company is in the final phase of negotiation with the software company.
You are responsible for a major strategic initiative that will be implemented using BPM …. and you’re losing sleep trying to figure out how to scope this BPM project. It’s not that this is your first run through the jungle – you were picked because of your experience, maturity and proven track record of success. You’re losing sleep because you are now facing a different set of animals in the jungle than you are used to.
Here are a few tips we’ve learned over the years that might help you initially scope your first BPM project. Consider basing your first estimate on these four factors:
- the skills of the people available to work on the project,
- the complexity of the processes,
- the screens that will need to be built for the user interfaces and
- the complexity of the integration to backend systems.
Of the four, the most critical is getting a firm grasp of the skills you have available. If this is your first project, be sure to include a mentor and just-in-time training as a part of your project plan. There are 3 primary reasons I’ve seen BPM projects fail – this (lack of skills) is on the top (along with a lack of leadership) in the reasons for failure. You’ll be tempted to multiply your estimate by 2 or 3 to overcome not having a mentor or skills. We’re all cost constrained – I get that, but don’t go into this without help from people who have successfully implemented several projects using the BPM software you’re getting ready to purchase.
Plan on having a high level process discovery session to work out the current pains you have and how you plan on solving them. From this, you usually discover the number of processes and get a rough idea on the number of activities inside the processes. It won’t be perfect, but an experienced business analyst should be able to get an idea of the number and complexity of the processes. As you go into this discovery session, recognize that you are just trying to get a general idea of what processes it will take to solve your specific problem in this project. The mistakes that are usually made here are: (1) it’s easy to go too deep – keep reminding yourself this is a high level process discovery session, and (2) you will sometimes focus on the wrong jungle – this happens when a tangential discussion pops up and it winds up heading us down the wrong trail, and (3) you try to model your entire organization and all of its processes – a useful exercise in another setting, but it is not what you should be doing when trying to estimate / scope a BPM project. It’s critical during one of these sessions to have a skilled facilitator who is comfortable modeling business processes and who has the people / facilitation skills to keep things going down the right path.
From the number of activities in the process, you can determine the number of screens you’ll need to build for the interactive human activities. Screens obviously can vary in complexity and your experience in building them is critical in determining how much effort this will take. If you’re planning on having a well defined specification (e.g. use cases and sample screens) plan on spending much less time as you prototype them to end users later. The time spent building a specification up front is time well spent, but if you don’t then factor in much more time as end users make you do many iterations of their user interfaces.
If:
- this is your team’s first project and
- they have never done integration to back end systems before using either a service bus or Oracle BPM directly and
- they have no one to help mentor them
then factor in at least two times the amount of time that your developers (the eternal optimists) are telling you it’s going to take. If the services you supposed to expose have not been built yet, make sure that your project has a phase 2 (your fallback plan when the services that were originally planned for phase 1 finally make it into production).