08/10/2003

Results or excuses?

The author, John Smart, is a senior consultant and partner of GreyDuck Technology.

At restaurants, I rarely tip less than 15% regardless of service. If the kitchen is slow then, while I know its not my server's fault, the chances he or she will get more than 15% out of me drops dramatically. I suppose it might be more fair of me to complain to the manager instead and tip my server only according to the things within his/her control, but in my mind the server represents the establishment.

Another analogy: I couldn't figure out why my flight from Minneapolis to Newark was scheduled to last about 45 minutes less than the return flight. Surely the jet stream wasn't THAT strong? On the return flight I got my answer: Northwest Airlines knows Newark. They knew we'd be sitting on the runway a while, and built that into the schedule. We were delayed half an hour or so but still arrived on schedule because their (and therefore my) expectations were set correctly.

Looking at your own business, there are projects that are delayed due to circumstances beyond your control and its not fair to measure you by it... but only if you conveniently forget that its how your customers measure you, and that's the metric that needs improving. When an external vendor doesn't complete its audit in a timely manner and therefore you can't respond to a customer's request, the customer is upset with you, not your vendor. Explaining "Well, we can't get our vendor to respond." just tells them that you're also refusing to take the blame for your problems.

When I was recently helping a company develop a system to measure and report on response times, we had initially considered flagging any applicable delays because the staff in part didn't want to be "punished" for things beyond their control. Our discussions included words like "alibi", "excuse", "legitimate reason"... Later we came to realize we should look at these things more in ways of categorizing only those delays that we want to track as part of an effort to improve performance.

If there's a known issue but you're willing to accept it as part of the system then, since you represent the system to your customers, you should take ownership of it and accept it within your own metrics. Otherwise, you need to ask yourself: Are you tracking results, or are you just tracking blame?