Continue in 2 seconds

Don’t Speak in Pronouns: Avoiding Ambiguity

Published
  • May 01 2005, 1:00am EDT
More in

To assure high information quality, one must avoid ambiguity in both information collection and in information presentation.

Information quality is not just about quality of data in our databases; it is about quality of all of our communication - spoken, written and displayed. It is a concept my wife and I call "Don't Speak in Pronouns." It comes from having analyzed the root cause of some of our moments of miscommunication.

Communication requires not just sending a message to someone, but assuring that the receiver correctly understands the essence of the message sent. There is ambiguity when time is represented as 9:45. Is it "a.m." or "p.m."? Representing a date as "03/04/2005" is also ambiguous. Is it March 4 or April 3?

Communication Failure

The following true story illustrates how ambiguity can cause people to interpret the same situation in different ways. I thank Alan Snow for allowing me to share it here.

Fellow consultants David, Bill and Charlie met one morning to plan for visiting Mike, an independent consultant, to discuss teaming up on a new project for one of Mike's customers. David was the only one who had met Mike, once, several months earlier; however, he had been in e-mail and occasional phone contact with Mike since then. Mike had given David directions to his house as none of the consultants had been there. In the car, David explained the directions to Bill, the driver. On the way, they discussed whether Tom, a friend of Charlie, could also help with the project.

As they got close to where Mike lived, David said: "He lives around here somewhere, but I'm not sure exactly where."

Charlie (who thought David was referring to Tom) said: "I think we just passed his (Tom's) street. It's back there on the left."

Bill did a quick U-turn and turned into what he thought was the street where Mike lived.

"What number?" asked Bill. "It's that house there," said Charlie, and they pulled up outside Tom's house.
At this point, Bill and David thought they were at Mike's house. Only Charlie knew they were at Tom's house, but assumed this was all part of the plan.

David rang the doorbell, and Tom came to the door. David said, "Hi, I've brought along Bill and Charlie to discuss the data warehouse opportunity at the XYZ company." (Tom seems to look somewhat like David remembers Mike looking, so David assumes this is Mike. Bill also thinks this is Mike. Only Charlie knows that it is Tom, but assumes they all know that!)

Tom, perhaps somewhat surprised by the visit, but nevertheless keen to work on the new project, says nothing to suggest to David or Bill that he is not Mike. The consultants discussed the opportunity and made plans to meet again.

They were all back into the car, enthusiastically discussing their new team alliance, when David's phone rang. Mike was on the other end, wondering where everybody was!

The moral of this story: misunderstandings like this happen all the time when we communicate in ways that are not explicit. We may laugh about them and accept them in good humor; however, such "failures to communicate" can have disastrous consequences when they occur between knowledge-workers, members of an information systems staff or among senior company executives making big business decisions.

Preventing Ambiguity in Information

The added value of information quality management processes that produce correct and complete information can be negated when information is presented ambiguously to the knowledge-worker or if the decision-maker makes a decision based on a false assumption or interprets information out of context.

This is too big a risk to ignore, and we should take care to ensure that information is presented accurately, labeled clearly and put in proper context:

  • Validate the query requirements with the knowledge-worker by asking, "What do you mean by...?"
  • Accompany a query "answer" with a clear and correct label and with any context required to interpret it.
  • Provide the query question in plain English rather than in query language statements and cryptic table names.
  • Validate that the information recipient has understood the explicit scope and meaning of the information provided.
  • Ask appropriately formed questions designed to uncover any potential for false assumptions or misinterpretations.
  • Ensure that any circumstances that affect the information are described in footnotes accompanying the information.

Although there may be some initial discomfort with this process among managers and decision-makers, its value becomes clear when misinterpretations and false assumptions are "intercepted" and corrected before any damage has been done.
What do you think? Let me hear at Larry.English@infoimpact.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

Don't have an account? Register for Free Unlimited Access