Organizations often treat their business performance management (BPM) project like other IT initiatives - relying on familiar employees to carry the load. With BPM, that approach carries certain risks. BPM is distinctive because it is typically deployed wide and deep across the organization, reaching end users from senior executives to knowledge-workers in multiple departments. Should you tackle a BPM initiative using only your in-house resources, or should you look outside for experts to help you along the road? It is well-documented that BPM projects have not gone too well when full responsibility was placed on staff with recent experience in deploying ERP and CRM applications. Instead, we've seen limited ROI and projects that were over budget or behind schedule. Some of the worst cases have involved full project failure due to lack of end-user adoption.
Based upon the combined experience of our BPM experts and a survey of 215 end users in late 2003, we identified reasons why BPM projects fall short of expectations. In this month's column, we'll look at mistakes that real companies have made, the risks involved, and then share our shocking (or perhaps not so shocking) conclusions with you.
We didn't fully understand our requirements. A common first step is to invite software vendors to present their capabilities and see if there is a potential match with your organization. This may seem logical, but it means you are looking at solutions without first defining the problem. It leads to assessing your BPM needs on the fly without using a proven methodology, and that is risky. There can be big, unpleasant financial and operational consequences to kicking off your BPM implementation without a plan of action. You basically have two choices when it comes to evaluating BPM requirements: rely on an appropriate, proven methodology or rely on experimentation and intuition. Experimentation - trying different approaches to find one that works - usually means a long series of "work-arounds" to make the chosen software system fit your situation. The methodology you need comes from experience and perspective. It's possible to develop your own methodology by experimenting, but that takes longer and will cost more in the end than getting outside help.
We didn't consider new ways to measure performance. During the phase of defining business requirements for a BPM project, companies may determine their internal business drivers accurately, but overlook the external metrics to which they should compare performance. This often results from internally focused analysis or selecting measures based upon "this is how we have always done it."
The BPM project is an opportunity to take a fresh look at your metrics, learn how your company compares to competitors and see how you perform against industry benchmarks. Balance your internal perspective with an outsider's viewpoint.
We picked the wrong things to measure. Metrics should be selected based upon your ability to take action if the metric so indicates. When the oil light in your car turns red, you know what to do, and you know there are very expensive consequences to ignoring that indicator. That's roughly comparable to a well-chosen BPM metric that tells you, "We are over budget and it's about to get much worse." The metric indicates a clear, specific action is required, and it's powerful enough to prompt corrective action.
We have seen companies get "metric-happy," and the result can be management meetings where reports with warning indicators are shrugged off. Maybe the metrics are overly sensitive and show inconsequential variances, such as employee retention slipping from 90 percent to 89 percent. It could also mean you are measuring something that is too global in nature to attribute to a specific problem, leading to a frustrating inability to take action and fix the problem.
We selected the wrong solution. BPM project teams can make the error of choosing their BPM solution based on the software vendor's marketing force or the personality of a salesperson. On the surface, BPM software solutions bear a strong resemblance to one another, and you may not be aware of differences until you are in the late stages of deployment - far too late to change horses. Important differences that can escape early detection are performance (speed) in real usage environments, ease of use by real end users, ease of maintenance, integration between various modules and future plans for enhancements. In addition, your company may require functionality that is not provided in sufficient depth by the software you've chosen.
A shortfall in any one of these areas can create headaches or even lead to project failure. If the vendor selection process is managed carefully, and the needs analysis and up-front preparation are done well, the chosen solution will be a good fit.
We paid for too much software and services. Software products always include functionality you don't need and probably don't want to pay for. However, as you get involved in a software transaction and a vendor generates enthusiasm for their vision of your project, there is a risk of getting caught up in the excitement. A word to the wise: many before you have bought modules that were not called for until much later phases of the project. Additionally, it's common for companies to buy more seats than currently needed, with hopes of future system expansion. Unless you are getting a terrific deal, just buy what you need today.
Vendors will often "bundle" more than you initially need at very attractive prices to increase your overall project price, with full awareness that you may not use all the licenses in the near future, if ever. Remember those 18 percent annual fees for upgrades and maintenance on existing software purchases add up. The additional annual maintenance costs get lumped together with maintenance fees of the product that you do need. Several studies by industry analysts have shown that nearly 20 percent of software licenses sold go unused. Again, buy what you need today.
Be the first to comment on this post using the section below.