The Argument Against "CASCADING"

I'll admit up front that the title of this post may be a bit misleading. But it does point to an age old problem in implementing a Balanced Scorecard...specifically, how companies respond to a critical choice point encountered in designing the scorecard itself.

One of the most important choices companies encounter during the very early stages of scorecard design and architecture is the decision of whether or not to "cascade" KPI's and to what level of detail.

The temptation of many is to cascade to the n'th degree, and build what I call the "never ending tree structure"...one that allows companies to keep breaking down measures and indicators until they can't break them down any more. In fact, some software applications actually encourage this process by building this "tree structure" orientation into the administrative interface itself.

In a weird sort of way, this is a self perpetuating prophesy. Software designers and some users are by their very nature analytic thinkers. You know the type- the kind of people who over intellectualize every problem they encounter. The ones who prefer to model and analyze everything they encounter, right down to their spouses if they would let them. And believe it or not, society needs these people. CSI agents, NASA scientists, golf or baseball swing coaches- all of these are great career choices for the hyper analytic crowd. But if its great performance management and business excellence you crave- stand clear!

What you want is enough "breakdown" analysis to make your objectives relevant to the managers and employees that accountable for driving positive change, but little or no more than that. Usually that means 2-3 levels tops, with maybe a level or two of trending where necessary. But just because your system or IT solution will enable you to go down 10 levels ( "pointing and clicking" on every bar chart data element until the cows come home) doesn't mean you should build that into your enterprise performance management solution. And just because you may need that level of detail for a custom report for one of your corporate CSI-type analysts to do his job, doesn't mean it should be a central design principal in your performance management process and supporting application.

Here are a few tips when faced with the IT capability of "cascading to your hearts content":

1. The level to which you drill down should be no more than 2-3 levels from your highest level business objective- any more will begin to lose that critical "line of sight" I've discussed in previous posts.
   
2. The lowest level KPI or business metric you select should be both measurable and MANAGEABLE- For example, you can drill all the way down to the tire or lug nut on the truck in your delivery fleet, but that level is rarely anyone's key accountability and hence may not be as "manageable" as you may think. And if by chance it is, then make it part of another context, or another scorecard, related to that specific business function- not part of your enterprise scorecard.
   
3. Every KPI should be tied to one or more high impact initiatives designed to drive business improvement, with the total # of strategic initiatives across all KPI's less than 20-30. Beyond that, the organization will begin to lose critical focus
4. Keep your scorecard layout simple and easy to understand, avoiding complicated multidimensional analytic graphics or causality relationships- leave these for the custom panels or your analytic core
   
5. Make EVERY view in your scorecard something that your CEO and Board COULD understand if they saw it. That's not to say they would typically view those screens, but they should be able to make a mental connection to something they care about.
   

In short, don't let your software capability drive your EPM process, but rather let your EPM process drive your software. After all, its called EPM for a reason. Said another way, if God had intended the ultimate in hyper analytic solutions for your EPM process, it would probably be called something like Micro Analytic Performance Management- maybe a cool solution for the BI crowd, but not something that should be top of mind for your management team.

-b