We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Performance Management: Myths vs. Reality, Part 1

Originally published September 14, 2010

With new vendors, new consulting companies, and new end users entering the business performance management (BPM) space for the first time, some old myths have resurfaced. The rush to embrace BPM can lead some to go in with false beliefs and expectations, while permitting others to take advantage of the relative lack of knowledge to suit their own purposes. This month we begin a new series that will try to debunk some of the most persistent myths we encounter while working with the performance management community.

Myth #1: Performance management projects are very similar to most other IT projects.

Companies that believe this then proceed to treat their performance management initiative like any other project and employ the same resources, roles and methodologies that have worked for other IT projects in the past.

Reality:
Performance management projects are different in several significant ways.

While BPM does share many similar traits with other large, complex enterprise projects, it does have some unique aspects that require a different approach to be successful. The biggest difference may, in fact, be the people who actually use it. While senior management may utilize output from an enterprise resource planning (ERP) system, for example, it is unlikely that they ever directly access the system themselves. That is not true with performance management. We have seen CEOs and members of the board of directors sign on to BPM systems to access the most current performance measures and trends. With this audience, the tolerance for non-intuitive navigation, slow response times, or inaccurate data will be very low. There is little room for error, and either the system or its developers/implementers may find themselves at risk if the expectations of this very demanding user group are not met. The way to minimize this risk is to make sure that the assigned project managers have significant BPM experience under their belts. As an example, someone who helped build a successful order entry system but never worked on a BPM project will be facing new challenges that can impact his/her probability of success.

Secondly, while it is almost cliché to say that business and IT need to work together, this relationship is at the core of determining whether or not the BPM project will meet its desired goals. For most projects, an IT manager meeting with the business users to gather requirements and periodically review progress and get sign-offs is probably adequate. For BPM, there needs to a be a cross-functional team consisting of members from IT, finance, and the business units working together on a regular basis for the duration of the project. Yes, this is a major commitment, but it is critical for project success. BPM is as much about business processes as it is about technology, and there is even some debate as to who should lead the project – finance or IT. We'll sidestep that question for now, but this really needs to be a team effort with good representation from senior team members throughout the company. Remember, unlike back-office processing or accounting systems, this is a mission-critical, high visibility, strategic decision-making tool. Cross-functional teams ensure success by tapping the unique knowledge of each area of the company, allowing every group to be heard and have their needs met, and ultimately aiding in end user buy-in.

Third, every company and every project has its fair share of politics. Remember though that BPM systems measure how the company, individual departments, and even employees themselves are performing. In some cases, compensation is tied back to these measures. When it comes to agreeing on the accuracy, quality and sources of the data as well as what is actually being measured, you will see political posturing and territoriality like you've never seen before. To put it simply, people will want to be measured on what they can most easily accomplish, not necessarily what is most important to the company (and probably a little more challenging to achieve). When they miss their performance targets, they will be quick to say that you are measuring the wrong things or the data is bad. They will probably even have a spreadsheet that they have been secretly maintaining to prove that they have the right numbers and the system does not. How do you avoid this? Senior management and independence. Some of the most senior members of the company need to be involved in setting the tone and determining what the system will measure. Since tough choices need to be made, these senior executives often involve an outside facilitator to run this process. This independent outsider can more easily help Joe in sales realize that his favorite pet measure doesn't make sense here but measuring his forecast accuracy, for example, (which he would rather not call attention to) does make sense.

The bottom line: Treating this like any other project and just throwing it over the wall to one of your IT project managers based on his successful track record with non-BPM projects is a mistake. Unless you really don't like the guy.

Myth #2: BPM dashboards and scorecards are essentially the same thing.

People who adhere to this myth use the terms interchangeably.

Reality: BPM dashboards and scorecards are closely related, but quite different.

This is an oldie but goodie and worth revisiting for a new generation of BPM adopters. A scorecard, as the name implies, is how a company scores or grades its own performance. It is a small collection of important measures known as KPIs (key performance indicators) that tie back to the corporate strategy. They can be supported by dozens, if not hundreds of other metrics. This scorecard can take any number of forms including a handwritten list posted on a bulletin board, a numerical report printout, or a graphical display.

A dashboard on the other hand is simply a graphical display tool usually utilizing stoplights, gauges, graphs, arrows and color cues. It is an ideal way to display and share the information contained on a performance scorecard. A dashboard populated with data from a scorecard is usually referred to as a performance dashboard.
The bottom line: Dashboards and scorecards are a marriage made in heaven, but as in any good marriage they retain their own individuality and purpose.

Next month – more from the BPM myth busters.

  • Craig SchiffCraig Schiff

    Craig, President and CEO of BPM Partners, is a pioneer in business performance management (BPM). Craig helped create and define the field as it evolved from business intelligence and analytic applications into BPM. He has worked with BPM and related technologies for more than 20 years, first as a founding member at IMRS/Hyperion Software (now Hyperion Solutions) and later cofounded OutlookSoft where he was President and CEO.

    Craig is a frequent author on BPM topics and monthly columnist for the BeyeNETWORK. He has led several jointly produced webcasts with Business Finance Magazine including "Beyond the Hype: The Truth about BPM Vendors," the three-part vendor review entitled "BPM Xpo" and "BPM 101: Navigating the Treacherous Waters of Business Performance Management." He is a recipient of the prestigious Ernst & Young Entrepreneur of the Year award. BPM Partners is a vendor-independent professional services firm focused exclusively on BPM, providing expertise that helps companies successfully evaluate and deploy BPM systems. Craig can be reached at cschiff@bpmpartners.com.

    Editor's Note: More articles and resources are available in Craig's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Craig Schiff



 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!