KPI, metric, measure: Huh?

KPI, metric, measure: Huh?

I recently read an interesting discussion on LinkedIn asking "What is the difference between KPI, metric, and measure?"  When I was first notified about the discussion, I thought "That's easy to answer."

Then I started reading all the answers; some thoughtful, some insightful, some trite, some silly, ... you get the idea.  But it did point out that terms we in the IT world use frequently may not be universally defined.

So, here are my definitions, take 'em or leave 'em.

KPI

A Key Performance Indicator (KPI) is the use of a metric that the business has defined to provide management with a quick analysis of how the business is doing in the area being measured that is considered critical.

Notice how I used metric and measure in that definition?

Metric

A Metric is a relationship of a measure to something that will indicate some degree of good or bad, success or failure, improvement or degradation such as time, distance, repetitions, events, etc..  For example, miles per hour, gallons per minute, kilowatts per hour; each of these can be given some rating or ranking in a hierarchy.

100 miles per hour might be an "Unsafely Fast" metric on a two-lane road, but be "Very Slow" on a NASCAR race track.

Notice how metrics are made up from measures?

Measure

A measure is fixed indicator of something that can be quantified such as count, size, quantity, dimension.  Examples are 2 apples, 15 inches, 8 ounces, 10 acres.

Notice that measures are at the bottom of this hierarchy.  Measures are used to define metrics which are used to define Performance Indicators which may become Key Performance Indicators.

Notice that I snuck in a level between metric and KPI?  There can be many performance indicators, but there should be few Key Performace Indicators.

What is the role of a Data Manager

As a companion to my blog "Must I become a manager?", I thought I would pass on Steven Feuerstein's thoughts on "what are [data managers] good for?".  Once again, I have replaced reference to developers with data-related terms (enclosed in []).

These are goals, I feel, of a good technical lead, too, but as a technical lead, we may not have much direct control of all of the items Steven lists.  His words:

I have been thinking about this lately: what are [Data Managers (DMs)] good for? What should they do, and do for us, "lowly" [data specialists]?
I will write on this more fully in 2010 on my ToadWorld blog, but I thought I would close out the year with a few quick thoughts you might appreciate:

1. The whole point of a [data] manager is to help [data specialists] get their jobs done. In other words, "it's the code [deliverables], stupid."
2. The most important thing a DM can do is shield [data specialists] from time pressures. Of course, there are unrealistic deadlines with which to contend. But you won't get better [deliverables] from [data specialists] by pushing them to finish sooner. You will just get buggier software  [poorer deliverables].
3. [Data specialists] should get the offices or cubicles with more space, lots of windows, sunlight, etc. They are creating things and solving problems. They need the physical space to inspire them.
4. Status meetings are for the most part expressions of power by DMs. The message is "my time is more important than your time." Cancel the status meetings, DMs! Instead, meet with each [data specialist] and get their status directly from them.
5. The most important question a DM can ask a [data specialist] is "How can I help you get your job done more effectively?" 

Comments?

Must I become a manager?

I just got an email from Oracle SQL Programming (by Steven Feuerstein, www.ToadWorld.com/SF, www.stevenfeuerstein.com) that got me thinking about my career path.  I have a consultant's approach to my career.  By that, I mean I am perfectly content to be good, very good, at what I do and meet or exceed my client's needs while passing on my knowledge (mentor) to those who will have to pick up and support what was done after I'm gone.

I have progressed from Data Communications to DBA to Data Development (PL/SQL, SQL, C/C++, shell scripts) to Data Analysis to Data Modeling and now Data Architecture.  My career has been mainly as a consultant; I have worked as an FTE for two consulting firms but was always contracted to clients.  My last FTE position with a consulting firm required me to be promoted to their Manager level or leave the company.

Now that I am old enough and experienced enough to be considered by some as an expert (I never like to call myself an expert because there is always someone who knows something I don't know.), must I become a manager?

I do not want to become a PM, get PMI certified, and become a hands-off manager.  Technical lead positions are great, but not management roles.

Should someone be forced to advance up the corporate ladder or leave the company?  What is wrong with retaining people at a senior technical level?  After all, we aren't all qualified to be, or desire to be, managers just because we are good at what we do technically.  And some people, like me, may have had management positions we succeeded at (to some degree, anyway) but are more comfortable and happy at a senior technical lead role.

Steve Feuerstein's email article was about Developers and Development Managers, but I think his comments and perceptions hold true to Data Architects, which I consider to be at the top of the Data ... career path, and other Data ... positions toward Data Managers.

Quoting from his email, but changing "developer" to "data specialist", he says:

"You have probably heard of the Peter Principle, which can be summed up as "while jobs generally get more difficult the higher up any ladder you climb, most people only come equipped with a more or less fixed level of talent that corresponds to their intelligence, knowledge and energy. At some point, then, they will be promoted into a job they can't quite handle." Or to put it more succinctly: people are often promoted past their level of competence.

... I find that in the world of software, most [data specialists] have few good things to say about their managers - and not just because they read Dilbert. That's kind of sad, because lots of [data] managers (DMs) are former [data specialists]. To invoke the Peter Principle: just because you're a good [data specialist], doesn't mean at all that you will be an effective DM. But if you've been a senior [data specialist] for a while - and an especially good one - how does a company reward you except by promoting you...up to manager?"

Comments?