Business Intelligence Network - The Vision for BI and Beyond

The Common Performance Management Pitfalls

Published: November 14, 2005

Five surefire ways to reduce the likelihood of success for your business performance management project.

I’m often asked the same question by finance and IT executives who are looking to jumpstart their performance management initiative. The common question is usually phrased along these lines: “What best practices can I borrow when rolling out my BPM solution?” I’ve answered the question in a number of ways over the past few years, and have shared some best practices in the monthly Business Intelligence Network newsletters. But some organizations find themselves repeating the mistakes of others, not learning from those who went before them. 

To take a slightly different approach, let’s consider the things that you can do wrong which will maximize the likelihood of a project failure. In truth, you might make some of these mistakes and still roll out a workable solution, but you probably won’t be maximizing your payback from business performance management. Unfortunately, these organizations have to live with their mistakes for five to seven years. That’s a lifetime to operate with a sub-optimal performance management system. In today’s competitive environment, you don’t want your company to carry that kind of performance handicap.

Here are five surefire ways to reduce the likelihood of success for your business performance management project:

1. Be satisfied with an incomplete understanding of what you want to accomplish.

At the core of business performance management, you are establishing strong business processes that help you tie day-to-day operations back to the organization’s strategic plan, with departmental goals and individual objectives linked to the corporate vision. By not clearly stating your business requirements at the start of the initiative, you can easily wind up specifying a system that reflects individual departmental agendas, but not the overall strategy. 

It is the role of the leaders—the leaders of the BPM initiative—to confirm that the corporate strategy is clear before hiking down the path of their BPM deployment. This often demands the involvement of key stakeholders and an executive sponsor who can help crystallize the strategy if it remains out of focus. Then you can prioritize the business requirements, and from there the systems and business processes that need to be addressed. Trying to advance a BPM initiative without a clear view of your objectives is asking for trouble.

2. Think technology, then business processes.

IT executives often charge into the BPM technology assessment with a round of quick phone calls to vendors they’ve known. By getting a “lay of the land” early on, they expect to get an idea of best practices that could help them later when they are putting together an RFP or want to educate their business users as to what is possible with the new technology.

This approach can be haphazard, and often creates a bias early in the project’s life, sometimes focusing on intriguing product capabilities that are not wholly relevant to the business issues your company faces today. On the other hand, you could take the approach of first assessing your existing systems and business processes, and where they fall short in creating a performance-oriented culture within your organization. But that would make it too easy; you’d be able to focus on technology partners with a track record of addressing specific gaps, while appropriately aligning with your technical infrastructure and support requirements.

3. Let the vendors control what your audience will see in a demo.

Vendors know which features in their products show well, and they can exploit them to differentiate themselves from competitors. They take these aspects, and bake them into a well-rehearsed demo that is scripted and repeated hundreds of times for prospects around the globe. If your requirements align with the key functionality they have presented, it makes for a quick buying decision. Not a good decision—just a quick one.

It takes time and effort to clearly state your business requirements before the demo, and ask the vendor to customize their presentation in specific ways. You need to be strong about sticking to your requirements, and take the demonstrators “off script” so that you can truly see how their solution can address your needs. 

Keep in mind that this may take a bit longer to accomplish. You may have internal project deadlines, but don’t rush the evaluation, unless you want to make a faulty choice.

4. Don’t bother thinking beyond the incumbent ERP or data warehouse vendor—just buy what they suggest.

IT groups have been found guilty of jumping into a BPM solution by reflexively adding it on to their current ERP suite, rather than hunting for BPM-focused software vendors who might deliver a more robust solution. Yes, it’s comfortable to go with a known provider, and the ERP vendor’s BPM software can be expected to integrate well with existing systems, on a unified database. If that were the whole story, the one-vendor approach would be a no-brainer.
 
But the business users might not thank you. They don’t think about integration; they cheer for: ease of use, depth of BPM functionality, and reduced dependence on IT. The fact is, their wants come first, or the system won’t get the acceptance it requires to succeed. Business users tend to put best-of-breed BPM application vendors atop their list of favorites, and unless the integration problems are too much, IT should accommodate them. If IT gets to do what is solely best for IT, the system may never be fully embraced by the end users, so it ends up being underutilized. If Finance and IT get into a deadlock over best-of-breed versus ERP vendor, consider bringing a neutral arbiter—or at least a senior decision-maker who can see both sides—of the picture.

5. Don’t pay any more than you would for a business intelligence tool.

Companies often see business performance management initially as a different kind of reporting, a way to beef up Excel analysis. Not surprisingly, they expect BPM software to be priced like a reporting tool, not like an enterprise-wide system. In addition, organizations often try to make up a budget shortfall by reducing the amount of money required to correctly implement the product after the software is purchased.

It’s pretty much guaranteed that if you don’t give business performance management the respect it deserves, or the sponsorship and support from senior management that it needs, the budget won’t match the task, and you’ll end up with “mini-BPM” and “micro-payback.” 

If you’re stuck with a small budget, you must accept tradeoffs. Make sure they are the right tradeoffs. Usually, that means sacrificing functionality to keep the number of seats required for the adoption of the system to be successful. For example, it can make sense to give up consolidation in favor of getting planning and budgeting—which has lots of users—into action. With initial success across a wider population of users, you’ll find it easier to get support for buying more functionality.

Conclusion

With a sharp eye on the don’ts, it will be easier to follow best practices, with a structured approach; define your requirements, control the demos, and ensure requirements are met. Any company that committed the mistakes described above—and went on to select the wrong business performance management solution—can tell you the consequences are painful.