Simplifying BPM Implementations

Many BPM projects start with a big fan fair since it is the buzzword today across the globe. Organizations are skeptical to put their neck across new technologies; therefore, one should appreciate those few who take this initiative into their organizations. At the same time, it is equally important to do it the right way. In other words, achieving the project goals is not easy & this blog talks about some of the avoidable pitfalls associated with any BPM project & the best way to work around those pitfalls. A lot depends on the way the project is handled,how the vision is set & how various teams strive to achieve the project goals.

One of our customer’s objectives was to introduce BPM technology in their organization & educate users on how BPM will help them handle their business functions more effectively with better transparency into the process.

Changing the mindset – Traditional Application Development vs. BPM Process Implementation
Most organizations think of BPM projects as normal web-based application development. It is very contrary to that and needs a pilot first to determine the potential impact that BPM will have. Unfortunately, everyone involved, follows the traditional “schedule first” approach even for a BPM initiative. This results in sacrifices, and the project usually operates without the required buffer. Even if professional services are hired for consultancy & development, there is still a knowledge gap that relates the product capabilities to the business need. 
One such BPM project was actually part of a bigger end to end project (e2e) involving a web based java application covering the entire functionality. BPM scope in this e2e application was very small but the visibility it had was very high since it was one of the first BPM implementations. Therefore, even a small cosmetic bug on BPM part attracted the highest-level attention. One could attribute this to a basic lack of understanding of BPM technology.
Best Practice
Though this situation cannot be avoided entirely, the best way to cut down the risk will be by educating all the internal business users prior to the commencement of the project.

Tool Selection
Before selecting a tool, the organizations should ensure that it meets their current & future requirements. There are many tools in the market. Choosing the right tool ensure 50 % of the project’s success.
In many cases the BPM tool selection is an adhoc process and is based purely on the sales discussion. Though nobody can deny the need of a mature sales-cycle in the product purchase, it is important to conduct a thorough investigation into the claims made by the product companies. Many sales folks actually guide a customer properly to create a relationship of trust, but it needs time to build that trust. So get your technical people qualify the product companies claims. Take time to evaluate the vendors, do a proof of concept, and get to know your partners.  Rushing into a project by not doing your homework properly is a sure shot call for disaster.
Best Practice
Hire an independent third party consultant to investigate the product company’s claims, have demonstrations & ensure talking to existing customers. Document all the findings & ensure the product has the right mix of technology & flexibility to cater to all the needs.

Environment Verification Testing
Quite often a simple question is asked where there are multiple environments in a development project, “are these environments identical?” and its answer can be elusive. Believe me, there should not be any other answer than “Yes” to this question. It is very important for the person responsible to be able to answer that question – quickly and accurately – so that any defects in the application can be categorized as “application defect” or “environmental defect”. One such project was faced with a similar issue & it took the development team to re-build test processes to eliminate the possibility of any errors. It was only after that validation that the support team started debugging the issue. This already had done enough damage to the teams’ morale and add to that the time lost. The environment issues can be compounded by version upgrades. Organizations have to ensure that the environments are consistent.
Best Practice
Be able to prescribe what the deployment environment should look like, and have a capability to test and verify it quickly.

Integration
Globally it is well known that the most difficult part of any BPM implementation is integration,  If two teams are building a bridge from either side, be 100% sure that you are going to meet in the middle. Integration involves multiple departments, teams & multiple applications. It is often seen that lack of proper planning & inconsistent data are highlighted during integration phase which are then carried over in to the UAT phase. Under such situations completing the mission not only requires integrating existing application systems, but also during the process of establishing the system, the ability to get each department involved to work as a single team. It is important to own the responsibility of introducing the BPM concept and not try and shift responsibility to others, because collaboration is the key to the success or failure of a BPM initiative.
Best Practice
Identify the integration points well in advance to have a solid integration strategy. Make sure it gets validated by a system architect. Ensure that the integration testing plan is in place & is executed to the last detail available.

Over Customization
Quite often, it is seen that business users who actually are not involved in the initial BPM roadmap phase term the change as a threat to them & are very rigid in accepting anything less than what they want from the BPM implementation. This may well be an all dancing application. The result – over customization and an inflexible solution.
Best Practice
Begin User Involvement on Day Zero. This ensures that the adoption slowly builds over time. It is important to identify a process champion to validate changes/ suggestions from a need perspective without letting the core requirements and product functionality go haywire.

Manage Vendors Wisely
IT projects basically involves close interaction with software vendors, consultants and other external resources. If third-party relationships are not managed well, even the strongest in-house team may have trouble concluding the project successfully.
When managing both technology and service providers communicate your expectations loudly & clearly. Managing these well from both sides will contribute a great deal to project success.
Best Practice
Success comes from cooperation, rather than conflict, with vendors.

BPM projects are an ongoing journey with lots of roadblocks which may be very frustrating. Nevertheless, believe me; they are very easy to overcome. The appropriate tools, mechanisms & correct handling of the BPM project will help avoid the common pitfalls.
The journey does not end at the implementation. It is then time to sit back, analyze and plan the next steps for adapting & improving current process in to the BPM journey.