Copyright © 1998, Naomi Karten
Permission is granted to reproduce or excerpt this article if proper credit is given in this format:
Reprinted/excerpted with permission. The Training Doctor, www.trainingdr.com. Author: Naomi Karten.

Are You In Data Denial?

Years later, we were driving home from Vermont on a drizzly, dreary Sunday when the car started acting funny (a technical term meaning something is wrong and I don't know what). Then the dashboard began to glow with indicator lights. We should have stopped immediately. Instead, we continued to the next exit. The result? A cracked block and a major repair bill. Oh, and a hotel bill since all the repair shops were closed on Sunday. And a car rental bill, so we could get home while our car was in the shop and then back again to retrieve it. Afterwards (long afterwards, when we were able to laugh about it), we thought about our professor telling us: "The data are trying to tell you something."

Caution: ignore the data at your own risk

Now, I've always been of the "data is" school. "Data are" sounds too grammatically particular to me. Nevertheless, our professor's statement reinforces a very important point: that if you ignore the data - the numbers, indicator lights, customer complaints, project glitches, recurring outages, or whatever - you could misinterpret or remain oblivious to even the most obvious signs of trouble and suffer uncomfortable or expensive consequences. Such as getting stranded in a tiny Vermont town on a cold, damp Sunday.

If you work with customers, you probably don't have indicator lights that start flashing to signal something is wrong. That's why it's important to continually gather and assess service data so that you can identify patterns and trends, and know both what you're doing well and what needs adjustment. You need to be alert to situations that are exceptions to routine operations, such as a sudden increase in calls about one particular problem. When an incident occurs that clearly deviates from the norm, it could be a sign that something is seriously wrong. And the best course of action may be to STOP what you're doing, and ask: "Is the data trying to tell me something?"

The absence of a pattern you might reasonably expect is also data. For example, if a product upgrade routinely leads to a spike in call volume, and you've yet to receive a single call following last week's upgrade, that absence of calls is itself data. It could indicate anything from a meticulous, well-thought-out upgrade plan to customers so disgruntled by shoddy service that they no longer call for help. Knowing which it is could make a huge difference in what you do next.

Data, data everywhere, but . . .

Despite the critical importance of service data, many groups do a less than superb job of gathering and examining it. Either they don't collect it at all, or they do little or no analysis of it once it has been collected. For example:

• Survey data. It's the rare organization that hasn't run a customer satisfaction survey. But what's done with the completed surveys? In numerous organizations I've visited, the answer has been: not a thing. One manager told me, "Well, I put them in this drawer," and he opened his bottom drawer to show me the stack of completed surveys. If you've collected customer feedback and analyzed it and modified your service strategies based on that feedback, you are an exception. Unfortunately, for many organizations conducting a survey is an end in itself, not the means to improved service effectiveness.
• Customer support data. Many help desks and customer support groups do an excellent job of gathering data. In fact, they collect oodles of the stuff: call volumes, problem resolution times, caller profiles, statistics galore. Software that automates the data collection function makes this process both feasible and tolerable. Nevertheless, many support groups use the data primarily to track and service customer calls. They don't analyze it to gain insight into changing patterns, problematic trends, or opportunities to provide better service. And few groups share their service data with their customers so that they can work together to reduce problems and optimize service delivery.
• Training data. Training continues to be one of the most vulnerable of all services: the least appreciated, the least valued, and the first to go when times get tough. Nevertheless, many training groups contribute to this sad state by doing little or no follow up with students to assess training effectiveness. Instead, training data tends to focus on raw numbers - the number of people trained, courses presented, new training programs implemented, and so on - rather than evidence of business value that will help to justify training services to management. The growing use of technology-based training is exciting; nevertheless, the mere fact of its use will not be proof of its value.
• Project data. Sometimes the very steps taken to expedite completion of a project, like omitting critical testing ("it's just a small change"), only serve to make things worse. Sure, the project appears to have been completed sooner, if all you're tracking is the implementation date. But how much additional time is subsequently spent rectifying what should have been done correctly to start with? How much time is devoted to re-doing and fixing and patching and recovering, so that things function the way they ought to? That amount of time is data that is trying to tell you something. And if you don't know the amount of time, beware: It could be bigger than you think. Much bigger.

Are you in data denial? Do you need to do more to collect pertinent data, analyze it, and modify your strategies based on it? Be careful: ignorance of the data is not bliss.

© 1998 Naomi Karten, www.nkarten.com