After many years as a performance management enthusiast, I sometimes forget how much confusion there still is around the topic. Since I’m a big believer that standardized language helps reduce confusion, I’ve decided to summarize some of my deeply held beliefs on performance management:
An objective describes what you want to accomplish. For example, ‘win the race’. A key performance indicator (KPI) monitors progress towards a specific objective. For example, ‘position among the runners’. A target is the value of a KPI at a defined moment in time. For example, in order to win the race, the target value for the KPI needs to be 1 at the end of the race (but not necessarily throughout the race).
Obviously the actual value of the position KPI can change over time, as various runners speed up and slow down (or even leave the race). In a similar manner, you should apriori set target values for different moments of time. That way, you can compare your actual value to the target value at specific intervals to know if you are on track.
(This 2008 post describes more about objectives, KPIs, and targets using the analogy of a race.)
I’ve noticed that many people forget that targets can – and should – have multiple values and instead focus on the ultimate result: zero defects, $100M in revenue, or a 4.5 score in customer satisfaction. If the result is far enough away in time, comparing the current actual value to the eventual target value may lead to the mistaken conclusion that we’re not going to reach the objective. This is especially critical when results don’t happen uniformly. For example, in high tech sales, a disproportionate amount of deals happen in the last month of a quarter and in the last quarter of a year. A single target value would not capture this nuance.
(This 2007 post provides an example of multiple targets in a call center.)
A grading system compares actual and target values to determine a performance score. The closer the actual value is to the target value, the better the score. One of the most common systems is based on letter grades (A/B/C/D/F) in which 90% and above is an “A”, 80-90% is an “B”, etc. Unfortunately, this common scheme doesn’t work in many situations such as rewarding over-performance , grading on a curve, and dealing with defect rates.
In my experience most performance management practitioners don’t spend enough time creating the appropriate grading system that will help them understand (and explain) the size of the gap between actual and target. Unfortunately, this oversight means many of their performance conclusions are faulty.
Finally, organizations may use measures to track the resources that they consume and the product/services they produce but should focus KPIs on the results that they are trying to achieve. This distinction is codified in the Logic Model which describes the relationship between inputs, outputs, and outcomes.
The distinction between output and outcome also gives rise to some of my favorite performance management stories: the dirty KPIs in a city public works department, circumventing the CRM system in a call center, and keeping my own lawn green.
Do you have your own story of outcomes vs outputs that you’d like to share?
Yes Norman, I agree. To me performance and risk are essentially two sides of the same coin. We distinguish KPIs and KPRis today but it’s an arbitraty distinction that might disappear in some time.
As to your other point, I also agreed and I’ve written before that strategy shouldn’t be static (http://JonathanBecher.com/2009/06/21/strategy-shouldnt-be-static).
Jonathan,
Two quick points, with which I think you will agree.
1. Risk-adjusted performance management is the next level of maturity. Add KRI to your KPI; set your objectives with due consideration of risks and what you can do about them; recognize that 80% achievement with 5% risk of failure (to meet optimum objective) is often better than 95% achievement with 95% risk of failure.
2. Be prepared to adapt your goals and objectives. “Damn the torpedoes, full speed ahead” is not always the best business philosophy.
Output = 14 days.
At a recent staff meeting, an executive was explaining about how Lean methodology was going to be rolled out to our group. (This group covers a variety of responsiblities, but development is not one of them.) This executive focused on how our activities and projects should be designed to be completed in 14 days, as is the Lean recommendation for spliting up large development projects into 14 day chunks.
For some, 14 days would be an absolute luxury, though those ‘projects’ need a much shorter timeframe for resolution or completion. For others, ‘projects’ are controlled by some other entity, a partner or a customer for example, and we neither can break it into 14 day chunks nor ultimately control the duration.
Stressing this specific output of 14 days, this executive presented a message that left most perplexed and baffled. If the focus have been on some examples of outcomes, or even goals as applied to our group, it would have been much more clear in the audience’s collective mind about what areas needed our attention.