Why Most Balanced Scorecards are Subverted

  • Written By:
  • Published:


Business Management Issue

The 'Balanced Scorecard' has been a popular seminar attraction and hot topic in corporate boardrooms for years. Why all the buzz? Quite simply as Tom Peters puts it,' what gets measured gets done.'

The Balanced Scorecard, according to Harvard Business School professor Robert Kaplan, translates a company's vision and strategy into a coherent set of performance measures. The four perspectives of the scorecard - financial measures, customer knowledge, internal business processes, and learning and growth - offer a balance between short-term and long-term objectives, between outcomes desired and performance drivers of those outcomes, and between hard objective measures and softer, more subjective measures.

Yet many Balanced Scorecard initiatives never become practical or usable. Our analyses reveal both management and IT scorecard deployment issues that defeat its purpose, which are documented in Figure 1, and we define as subversion issues:

Figure 1: Balanced Scorecard Deployment Challenges

Management Subversion
IT Subversion
Allow bottoms-up initiatives that lack a sense of urgency and enterprise perspective Don't question initiatives that are bottom-up or lack enterprise perspective
Take too much to time to (re)align measures with strategy Don't align IT strategy to business change
Avoid accountability issues Build systems to avoid data ownership issues
Refusal to allow performance measurement to be interdependent IT avoids linking scorecard measures to transaction processing systems
Use pervasive suspicion of data (beyond the ledger) as an excuse for not fully deploying balanced scorecards Present data as facts and not business measures.

Business Implications

The Balanced Scorecard is intended to bring attention to enterprise issues. It depends on a hierarchy of accountability to deliver high performance processes that create measurable business value. A Balanced Scorecard will not fix management and accountability problems related to gaming the goals. For example, having the right set of delivery measures will not prevent managers from taking action counterproductive to the core process strategy. It will however make such actions (or inaction) more visible. To assure enterprise value, measures must be built from the top down. They must be relevant at each level; causing companies, divisions, department, and work teams to become interdependent. More than likely, this will put a strain on functional leaders not experienced in solving cross-functional problems.

Failure to address the IT issues related to the quality and availability of non-financial data, forces companies to rely only on the data they have and/or trust (hint: the financials). Lead indicators of performance such as customer, organization, and employee metrics take the back burner or are designed in an ad hoc fashion. Business are left with a myriad of measures that are either out of alignment with business strategies or irrelevant to strategy. Far worse is the likelihood that some existing measures are counterproductive and likely to defeat or delay strategic achievement.

IT Implications

Traditionally, large scale Balanced Scorecard programs are enabled with focused Executive Information Systems (EIS) with connections to financial and operational application systems. As a result, Balanced Scorecard initiatives are often not considered information systems projects and therefore, IT gets into the game late. As a result, IT departments often find themselves in the position of stalling the effort or committing resources that have already been committed elsewhere. Even when resources are committed to assist with implementation and data provisioning, IT frequently finds itself delivering data from "the most accessible" systems and not necessary the "most appropriate" one.

Unavailable resources are assigned to implement an unknown system that has executive steam behind it and provision it with data drawn from the wrong places. Can it get worse? Yes, it can! Data quality just might not be sufficient to satisfy the needs of the measurement system. We all know that it is only when data is used to measure people that it will become clean. We also know that data stewardship is a controversial issue. Balanced Scorecards enabled through Executive Guidance Systems force the issue through rigorous attention to operational definitions and challenges to them.

Architecture Impacts

IT professionals can put the 'balance' back in scorecard efforts by providing detailed architecture guidelines. These guidelines are the characteristics that the various components of enterprise systems should demonstrate to ensure synchronized/synergistic delivery of data to performance measurement systems. These guidelines must address:

  1. Operational definitions of data

  2. Data edit and quality assurance rules

  3. Definition of Systems of Record

  4. Data extraction and transformation rules

  5. Data summarization rules

  6. Data provisioning systems architecture

  7. Flags on inconsistent data

  8. Ability to audit data from inquiry or report back to system of record

Business Management Response

  1. Identify and fix your leadership issues before you begin.

  2. Be clear about your operational strategy before building measures.

  3. Involve information technology (data access professionals) people in the Balanced Scorecard business case development process.

  4. Identify operational data that will be used to populate the Balanced Scorecard as early in the process as possible.

  5. Be aware that measures will change over time. This will demand access to new data items. Often, focused implementations of Executive Guidance Systems do not leave behind the skills to make such changes nor are such changes supported by productive tools.

  6. Do not count on ERP (Enterprise Resource Planning) systems to fix data quality or access problems.

Information Technology Management Response

  1. Establish a Data Management architecture and governance systems early and ensure application.

  2. Design data provisioning systems into all applications paying particular attention to Systems of Record, Replicated Sources and Reporting Systems (Data Warehouse) assuring that data is extracted and interpreted consistently.

comments powered by Disqus