The Community Blog for Business Analysts


Best Practices - Ambiguity

How many times have you experienced a disagreement between colleagues, only find out later in the project that they were both correct. Chances are that they were using the same word, but both had different ideas of its meaning. [1]

I can derive hours of entertainment by playing word games with my friends, by picking a word they are using and purposely give it a definition that they are not thinking of. The important thing is that no one definition is incorrect, but it may be different.

For example, ‘Closing the door’; everyone knows when a door is closed and when it is not – don’t they? I might argue that no 2 people have exactly the same definition of a closed door. I might argue that a door that is ajar by an inch or so is actually closed. This is not strictly incorrect unless all parties involved in the conversation have agreed to a definition of a ‘closed’ door.

Obviously, this is not the sort of discussion that you want to have in the work place, but it is going to happen if not everyone has the same definition for an ambiguous term. Ok, you may say, but everyone in the work place has a pretty good idea (or at least a close idea) of what constitutes a closed door, such that we do not have to define it. Well if you are working for a word processing software company – yes; but if you are writing software for an application that controls submarines, and you want me to ride on that sub, I hope that the word ‘closed’ when referring to doors, was well-defined early in the development process.

My recommendation is to maintain a glossary of commonly used terms on your project that could cause confusion if open to several interpretations. We know that ideally requirements should not contain adjectives or adverbs, such as near, far, slowly or quiet. Sometimes we need to use these words on a project, in which case they should be defined in a glossary. For example; if we often use the word slowly, then define it as; Slowly – implies that the vehicle is traveling at less than 10% of its maximum speed.

I find that a RequisitePro project works well for maintaining a glossary of terms. MS Excel  and other spreadsheet applications may work equally well; so long as you can order terms, give them several attributes (acronym for example) and link them (as synonyms of each other, for example).

Next time you are in a disagreement with anyone (be it at work or at your local), listen to the words that they are using and try to figure out which ones are having a different definition applied to that which you are using. You’ll come to an agreement eventually (that is of course unless their objective in arguing is to maintain the argument).

Whenever possible, do not use a word (acronym or term) that is ambiguous, because you can be sure more than one interpretation will be used.

[1] I’m sure that we have all experienced this game as children. Leslie, I thought that I told you to tidy your room .. it is tidy .. no, it isn’t.

Editor's Note: Check out the list of all related best practices.

This entry was published on Feb 13, 2010 / Leslie. Posted in Requirements Management and Communication (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  2 members liked this article

Related Articles


Leslie posted on Friday, March 19, 2010 2:11 AM
These blogs read a bit terse and out in left-field when read by themselves.
It might help to read preceding articles on best practices starting with:

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC