Our Blog

Successful Scorecarding (part 3 of 5) – SC101 and Requirements Gathering

Craig Colangelo, Sr Consultant at PerformanceG2

June 23, 2009

We’ve spent time in previous posts summarizing where scorecarding fits in the larger CPM space, benefits/risks associated with implementation, and how to best realize scorecarding opportunities.  Now, we’re going to better define the solution itself and touch on some of the basics.

First, it is important to understand that scorecarding is not an IT solution.  IT is necessary, but not nearly enough to fully achieve an effective solution in this space.  A typical implementation does involve software, hardware, and other systems…but only to the extent that they deliver information to business users and drive performance in the right manner.

Many a scorecard project has failed because it was not designed or implemented to meet the strategic needs of executives, managers, and other decision makers.  Choosing the right business sponsor can go a long way in mitigating that risk.  Getting lots of business input and implementing the tool specifically to drive performance are also paramount to success.

There’s plenty of bleed over in the data presentation world and one solution may encompass several presentation methods.  Many confuse dashboards for scorecards.  Let’s cover a few differences:

  • Dashboards are generally more dimensionally biased and usually have the ability to add more dimensional contest.
  • Dashboards are more operational in nature and data is usually updated more frequently (hourly, daily).
  • Dashboards usually answer one or just a few performance type questions and performance is quickly gleaned with just a glance.
  • Scorecards are very performance management centric…think accountability, goals, performance improvement, etc.
  • Scorecards are more strategic in nature and data is updated less frequently (weekly, monthly, quarterly, annually).
  • Scorecards are generally less graphic.

Scorecard basics:

  • A scorecard is a collection of performance metrics designed to reflect the strategic goals of a unit in an organization
  • A metric is a measurement which has a target value; an actual value and an owner who is responsible for the performance of that metric.  A metric is related to a strategic goal.  They allow you to understand how you are performing.   Metrics and your scorecarding application answer key questions like …
    • How am I doing?
    • When has this happened before?
    • What drives this metric?
    • What could be causing the problems?
    • What other metrics and objectives does this affect?
    • What do I have to do about it?
    • Who else is included in the decisions?
    • Where does the data come from?
  • A metric type defines the behavior of a collection of metrics.  Metric types  typically identify one aspect of performance (such as revenue or expenses) defined by a performance pattern, for example:
    • Revenue has a performance pattern of “above target is positive”…you want revenue to be higher than target.
    • Expense has a performance pattern of “below target is positive”…you want expenses to be lower than target.
    • Inventory has a performance pattern of “on target is positive”…you want just the right amount of inventory, not too high and not too low.

Requirements gathering:

  • Make sure you have the right audience at the right time…
    • Senior leaders craft vision then formulate, articulate, and communicate strategy to their groups.  They are the ones ultimately responsible for performance in this overall scorecard area.  They hold their direct reports accountable for performance of their own metrics (metric owners).  A combination of senior leader + direct reports should define which metrics to use for each strategic objective.
    • Analysts help define where the data for the predefined metrics live, how their group would like the data to display, and a metric’s impact on other metrics (just their theory…you should definitely involve metric owners and senior leaders in this theory formulation).
  • Be ready to define the following during requirements gathering sessions…
    • Any graphics to support the strategic direction available (strategy map, balanced scorecard, road map, common mission statements, etc.)
    • Name users of the scorecarding system and their role (information consumer, metric owner, analyst, scorecard owner, SME, etc.)
    • For metrics, you’ll need some of the following information:
      • Business and technical descriptions
      • Owner’s name and contact info
      • Frequency of data
      • Data source for actual, target, and tolerance
      • Unit of measure, scale, and how it rolls up
      • Metrics that impact this metric
      • Metrics that are impacted by this metric
      • General groupings and location for metric on graphic
      • Supporting reports/analysis/dashboards for potential drill out
    • For scorecards, you’ll need some of the following information:
      • Scorecard name
      • Business and technical descriptions
      • Owner’s name and contact info
      • Hierarchy – where does this scorecard fit in the tree
      • Supporting documentation for the strategic initiative

That’s all for now.  We’ll touch on best practices and other general advice in next week’s post.

This entry was posted in General and tagged , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Comments are closed.

PerformanceG2 Menu