Continue in 2 seconds

BPM Pitfalls and How to Avoid Them

  • June 01 2004, 1:00am EDT
More in

Sshould You Tackle a BPM Initiative Using Only Your In-House Resources?

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.

We didn't prepare and listen to our users sufficiently. Isn't it frustrating when a new system goes unused? You cannot judge the project's outcome until after the investments are made and the project has been rolled out. True user acceptance (or lack thereof) may not be evident for 12 to 15 months after the project gets the initial green light. Low acceptance often indicates that the IT and finance-based project team, being focused on the implementation, didn't involve and inform future users. Outside consultants who understand the need for communication can ensure that the project is known, appreciated and addresses end user requirements, which results in a well-received rollout.

We've had limited success, but we've had to lower our original expectations. Typical BPM projects can take three to 12 months to rollout. During that time, your business may change in ways that force the project scope to shift. As the project manager adjusts the framework and scope of the project, original business goals can be forgotten. If project scope is reduced, the ability to deliver on the strategic goals can be significantly impacted.

Sometimes partial failure can be worse than total project failure. The system may produce enough benefits to keep itself alive, but the company is stuck with a suboptimal system and learns to live with it. Your organization is at a competitive disadvantage compared to others who have deployed more successfully. The budget has been spent, and you have a few years before you can realistically request funding for another project. The original stakeholders may understandably be reluctant to support another project when the first one failed to meet most of the strategic objectives.

We fell behind at the outset and never caught up. It's not uncommon to hear that while companies schedule four to six months for the selection of a BPM software vendor, they often become bogged down and spend more than six to nine months on selection. Here's a news flash: selection can, and should, take just four to six weeks. In the project phase, look at an outside expert as a way to save time and money, rather than viewing that expert as an expense.

What You Should Do

Do you have the impression that we champion the hiring of outside expertise to help guide your BPM project? If so, you are right. It can make the difference in your project's outcome, and it usually does save time and money. Given the youthfulness of the field of BPM and the relative dearth of experienced people, tackling BPM on your own is not advised in most cases. There's no need to outsource the entire project - but you should take advantage of a guiding hand at crucial points.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access