Business Intellegence

Many good articles have been written on how to succeed with BPM, particularly related to an enterprise’s first projects. They often cover project selection, tool selection, project team composition, deployment preparation and organizational change. All of these are important factors, successful BPM implementations change the way you do business. Any individual beginning with BPM would be well served by reading several of these.

In this article we will look at BPM project development from the other side and discuss factors most likely to cause failure. By enumerating some of these, we hope to help organizations avoid some of the most common mistakes. These are the issues that we have seen most often, but we are sure that other practitioners could produce different lists. As you read through this you will note that very few of the issues are technical, one of the main benefits touted by BPM vendors is that their product reduce the complexity of building custom business applications. We find that this is largely true. The organizational obstacles are much more significant; particularly while the approach is still unproven. While implementing your first project you will have some supporters, probably a larger number of skeptics who need to be convinced and a few people who oppose or feel threatened by the initiative. The attitudes and actions of these people will have a significant impact on the outcome and acceptance of your early BPM projects. By avoiding these common obstacles, you can give your project much better odds of success.

The rest of this article is a top-ten list of things to avoid.

1. BPM is a new toy bought by IT without a solid business sponsor. IT is forced to search for projects to justify the expense, but the business owners aren’t convinced that they need it. If the business users were not involved in product selection, the chosen tool may not match their needs. The business units don’t have budget or resources for BPM projects. They may resist a new approach being pushed on them. In some cases, IT uses it within their organization in an effort to claim success, but the savings are unlikely justify the expense, or lead to wider adoption.

2. The business decides to implement BPM without support from IT. Note, this is the opposite of the previous item. Success requires engagement from both the business owners who will reap the benefits and IT who will implement and support the solution. BPM is never truly a standalone solution, it is a layer on top of existing applications and infrastructure. Without proper consideration from IT before selection, the tool may not fit well into existing infrastructure.
3. Selecting projects without sufficient benefit. Despite what you hear from the vendors and consultants, implementing BPM is expensive. The BPM suite, hardware to host it and implementation costs quickly add up to several hundred thousand dollars. We define success from the viewpoint of a shareholder. A process can be implemented and operate exactly as planned, but still be a failure if the ROI is negative. This is the most common failure which we have observed.
4. Over-reaching on the first project. If BPM is a new approach for your organization, it is best to start with a relatively simple project. This risks violating the previous item, but there are often high value low risk projects. Look for projects with narrow organizational impact, preferably a single department, but which have high volume or high cost of errors. These can produce significant value while avoiding many of the cross-organizational problems. A variation of this is starting several projects in parallel before completing any. The few knowledgeable resources are stretched across multiple projects, and each project makes similar mistakes without the opportunity to learn from prior activities.
5. Too many dependencies outside of the BPM project. While most BPM projects require interfaces to existing systems and infrastructure try to minimize external dependencies. Look for projects which can be implemented with existing interfaces. If possible, defer some of the integration to a second release. It will be much easier to get the budget and cooperation needed to modify existing systems after you have proven the value of BPM. If your organization has a mature SOA architecture, leverage that for all of your external interfaces. This will simplify your development task, and win key allies.
6. Poorly defined measures of success. Before starting any process improvement initiative, it is essential to measure the current performance, and the expected benefits. At the end of the project, management will expect a proper accounting of costs and benefits to determine whether to continue with additional BPM projects. Reduced cost is often the most obvious benefit, but also consider expanded business opportunities, better ability to respond to change and other improvements. Expanding revenue is often more beneficial than reducing costs.
7. Lack of high level, high visibility measures/reports. Too often, BPM developments do not include reports/dashboards/measures that can easily speak to senior management and decisions makers. These items are usually simple reports or charts and can include individual user/team performance metrics, statistics of use per product/product line, overall completion time of processes, etc... Taking the time to define these key metrics before starting the BPM implementation and designing the processes around the collection of these metrics is crucial in proving the added value and ROI of BPM.
8. Absence of an executive sponsor. We have suggested keeping the scope of the early projects narrow both organizationally and in terms of IT impact, but it is inevitable that any BPM project will require resources outside of the core project team. These will include IT resources as well as business experts to define the correct processes. An executive sponsor at a sufficiently high level to ensure timely availability of these resources is critical.
9. Underinvestment in training. BPM is a fundamentally different style of application development than traditional approaches. In particular it brings Business Analysts and other less technical people deep into the development process. Many companies skimp by training just a few core resources and expecting them to train the rest. But these resources are just developing their first BPM solution and do not have the expertise necessary to effectively train others.
10. Absence of proper in-house resources to develop and maintain the BPM software and applications. Contracting out the implementation of the first BPM projects is usually the fastest and more reliable way to start using BPM. However, without in-house resources that actively participate in this process and take ownership of BPM from both the functional and IT standpoints, the project may experience issues that are not properly and timely handled; resulting in undermining the end users confidence/buyout into the application and destroying the reliability/reputation of the project