I enjoy sailing. I also enjoy taking guests (let’s assume they are my customers) sailing. But what I enjoy about sailing might not meet the expectations of my guests. I may be having a great time while the boat heels to 35º and water rolls over the gunnels, or when the boat sloshes up and down (and up and down) through the waves, or when we listen to Jimmy Buffett CDs while sitting in 98º heat with no wind to be found. I may think it’s a great sail while my guests turn a color somewhere between yellow and green and begin begging to go home.
You may think things are great, but your customers may be turning yellowish green because things are not great for them. My point is that you must measure success not by your standards, but by your customers’ standards.
IT departments sometimes fall into the trap of measuring success solely on project-management parameters or technological criteria. The age-old example still applies too often:
IT says: “You got what you asked for…”
Business says: “Yeah, but it’s not what I need…”
Here’s a non-IT example to illustrate the point. A few years ago, I was working with a training department. They were extremely proud of the number of classes they held, the number of trainees they “got through” the claims training program, and their graduation rate. As I recall, they graduated 97% of the people who took the classes, but they were sailing without regard to their customers’ expectations. They looked at the training activity and the graduation rate as measures of success; however, of the 97% who “got through” the training, 30% to 40% were unable to perform the job for which they had been trained.
The managers of the claims department (the yellowish-green customers) who were receiving these newly trained employees were frustrated by the high number of the new employees who couldn’t perform their jobs at an acceptable level, and many had to be retrained by the claims department. Those who could not be trained the second time were let go after a lengthy termination process.
In this situation, the training department felt it was doing an excellent job, whereas the claims department felt the training department was a failure. It’s the classic example of judging success by an incorrect standard.
Instead of looking at the number of classes conducted or the graduation rate, the training department should have studied the impact or results of their training effort. An outcome where 30% to 40% of the graduates are ineffective and require retraining does not reflect success. In such a case, it is critical to get the two departments to work through the problem to:
• Revise the curriculum and testing to meet the claims department’s needs
• Revise the training department’s measurement of success by using statistics from retraining and forced turnover (for inability to learn the job) in the claims department
In the case of IT, the degree to which automation meets the customer’s true needs should be a key success measure. Using that measure means that the requirements gathering process has to be very effective—not just gathering requirements, but understanding the underlying business need.
When I sail with guests, we discuss their expectations and I try to measure the success of the sail not by my standards but by those of the people who will truly judge my performance. After all, it’s their perceptions of the sail that really count.
Comment on this blog at www.insurancenetworking.com
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access